From sip-bounces@ietf.org Sun Oct 01 22:16:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDHE-0001C2-RN; Sun, 01 Oct 2006 22:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUDHD-0001Bu-Ox for sip@ietf.org; Sun, 01 Oct 2006 22:11:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUDHC-0004vp-BD for sip@ietf.org; Sun, 01 Oct 2006 22:11:27 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2006 19:11:26 -0700 X-IronPort-AV: i="4.09,242,1157353200"; d="scan'208"; a="44431538:sNHT58099644" 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 k922BQVp030964; Sun, 1 Oct 2006 22:11: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 k922BPdM025029; Sun, 1 Oct 2006 22:11:25 -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); Sun, 1 Oct 2006 22:11:25 -0400 Received: from [10.86.240.151] ([10.86.240.151]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Oct 2006 22:11:24 -0400 Message-ID: <4520754C.9050108@cisco.com> Date: Sun, 01 Oct 2006 22:11:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Udit_Goyal@3com.com Subject: Re: [Sip-implementors] [Sip] PRACK query References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2006 02:11:24.0852 (UTC) FILETIME=[0FD5AF40:01C6E5C8] DKIM-Signature: a=rsa-sha1; q=dns; l=3294; t=1159755086; x=1160619086; 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-implementors]=20[Sip]=20PRACK=20query |To:Udit_Goyal@3com.com; X=v=3Dcisco.com=3B=20h=3DcqWzxksBI8mA6+p6Y2dLKMxoaNw=3D; b=c8WfTBp0Pi3B6BavHnTmcTVVzMtJL6IXBFnk3B9INtuSW/tCltN3CSyeAjZNJKqrzkMzDIV5 nqk0tDAn2JxUAczmDsl+dwsyMJWrsFJbJJm4s5YjegVgtNsnidacj4sW; 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: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, "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 Udit_Goyal@3com.com wrote: > SDP in 1xx response and 200 OK can be different because of early media > announcements and actual calle connected. > > If 200 OK SDP will be same, then how can early media will be > differentiated with regular session > (basically early media is used for announcements and 200 OK will tell the > actual callee connected) You cannot just change the SDP between the 18x and 200 because of early media. In a single dialog these are required to be the same. (Or, if the 18x was reliable, then the SDP in the 200 can (should) be omitted. Another possibility is that you get a 18x with SDP in one dialog, and a 200 with a different SDP in a different dialog. In general you can't differentiate between early media and regular session media when using the "gateway model". (See the early media RFCs for more detail.) Paul > Regards, > Udit > > > > > "Christer Holmberg \(JO/LMF\)" > 09/28/2006 07:46 PM > > To > Udit Goyal/C/US/3Com@3Com, > cc > sip@ietf.org > Subject > RE: [Sip] PRACK query > > > > > > > > Hi, > >> Please let me know if my understanding is correct for regular session > offer-answer when PRACK is used: >> For INVITE containing SDP, and if offer answer done in the using > reliable 183 response for early media, 200 OK response SDP will have an > answer for the >> regular session, so 200 OK SDP will be answer to the offer sent in > initial SDP. > > Yes. > > Of course, since you have already received the answer reliably, you > really don't need to care about the SDP in 200 OK, but according to the > rules it should be the same as previously sent in 18x. > > >> Similarly, if INVITE does not have SDP, and if offer-answer done using > PRACK, still 200 OK will contain the regular session offer and answer > will be >> present n the ACK message. > > I would assume so, yes. But, again, you don't really need to care. > >> Similarly, if UPDATE is used for offer-answer before call is connected, > it will not affect the regular session offer-answer, it will be taken > care by >> initial INVITE , final 200 OK and ACK message. > > I don't know what you mean by "not affect". > > If you send an offer in INVITE, and receives an answer in a reliable > 18x, the offer/answer exchange in UPDATE will then replace the one > previously done. > > But, yes, the SDP you get in the 200 OK should still be the same that > you got in 18x, even if you have performed offer/answer exchanges after > that. > > At least this is how I understand it - but you can never be sure when it > comes to offer/answer :) > > 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 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 02 05:58:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKVC-00078G-E3; Mon, 02 Oct 2006 05:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKVA-00077y-6o for sip@ietf.org; Mon, 02 Oct 2006 05:54:20 -0400 Received: from plmler5.mail.eds.com ([199.228.142.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKV7-0005ZZ-Dj for sip@ietf.org; Mon, 02 Oct 2006 05:54:20 -0400 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler5.mail.eds.com (8.13.8/8.12.10) with ESMTP id k929s359032552; Mon, 2 Oct 2006 04:54:07 -0500 Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.8/8.12.10) with ESMTP id k929ruHR000916; Mon, 2 Oct 2006 04:53:56 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.8/8.12.10) with ESMTP id k929rtbn000911; Mon, 2 Oct 2006 04:53:55 -0500 To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: Udit_Goyal@3com.com Date: Mon, 2 Oct 2006 15:27:27 +0530 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 10/02/2006 02:53:55 AM, Serialize complete at 10/02/2006 02:53:55 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: sip-implementors@cs.columbia.edu Subject: [Sip] Early media query X-BeenThere: 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="===============0189786755==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0189786755== Content-Type: multipart/alternative; boundary="=_alternative 00366597652571FB_=" This is a multipart message in MIME format. --=_alternative 00366597652571FB_= Content-Type: text/plain; charset="US-ASCII" Hi, I want to made an application where we can use early media for playing initial in-band announcements, and then finally connecting the caller to actual callee (eg prepaid card application). I want to know which is the correct way to support this as per SIP RFC. Method 1: Caller Callee | | | | |(1) INVITE with offer | |---------------------------->| | | | | |(2) 183 with answer 1 | |<----------------------------| | | | | |(3) 200 OK with SDP | |<----------------------------| | | | | |(4) ACK | |---------------------------->| | | (2) contains SDP of announcement server (3) contains SDP of callee Method 2: Caller Callee | | | | |(1) INVITE with offer | |---------------------------->| | | | | |(2) 183 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| | | | | |(5) 200 INVITE with sdp | |<----------------------------| | | | | |(6) ACK | |---------------------------->| | | | | | | | | (2) contains SDP of announcement server (5) contains SDP of callee Method 3: Caller Callee | | | | |(1) INVITE with offer | |---------------------------->| | | | | |(2) 183 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| |(5) 200 OK | |<----------------------------| | | |(6) ACK | |---------------------------->| | | |(7)Re-INVITE with SDP | |<----------------------------| | | | | |(8) 200 OK with SDP | |---------------------------->| | | |(9) ACK | |---------------------------->| (2) contains SDP of announcement server (5) contains no SDP (7) contains SDP of callee (8) contains answer of caller for callee offer Her, UDATE can also be used instead of Re-invites. Method 4: Caller Callee | | | | |(1) INVITE with offer | |---------------------------->| | | | | |(2) 183 with answer 1 | |<----------------------------| | | | | |(3) PRACK | |---------------------------->| | | | | |(4) 200 PRACK | |<----------------------------| |(5) UPDATE (callee offer) | |<----------------------------| | | |(6) 200 UPDATE (answer) | |---------------------------->| | | |(7) 200 INVITE | |---------------------------->| | | |(8) ACK | |---------------------------->| In this case, when callee answers, UPDATE is sent to caller to negoitate audio with caller, and then 200 OK is sent for the initial INVITE. Regards, Udit --=_alternative 00366597652571FB_= Content-Type: text/html; charset="US-ASCII"
Hi,

I want to made an application where we can use early media for playing initial in-band announcements, and then finally connecting the caller to actual callee (eg prepaid card application).

I want to know which is the correct way to support this as per SIP RFC.

Method 1:


                 Caller                        Callee
                   |                             |
                   |                             |
                   |(1) INVITE with offer        |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(2) 183 with answer 1        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(3) 200 OK with SDP          |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(4) ACK                      |
                   |---------------------------->|
                   |                             |


(2) contains SDP of announcement server
(3) contains SDP of callee


Method 2:

                                        Caller                        Callee
                   |                             |
                   |                             |
                   |(1) INVITE with offer        |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(2) 183 with answer 1        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(3) PRACK                    |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(4) 200 PRACK                |
                   |<----------------------------|
                   |                             |
                   |                                    |
                   |(5) 200 INVITE with sdp      |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(6) ACK                      |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |                             |
                   |                             |

(2) contains SDP of announcement server
(5) contains SDP of callee


Method 3:

        Caller                        Callee
                   |                             |
                   |                             |
                   |(1) INVITE with offer        |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(2) 183 with answer 1        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(3) PRACK                    |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(4) 200 PRACK                |
                   |<----------------------------|
                   |(5) 200 OK                   |
                   |<----------------------------|
                   |                             |
                   |(6) ACK                      |
                   |---------------------------->|
                   |                             |
                   |(7)Re-INVITE with SDP        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(8) 200 OK with SDP          |
                   |---------------------------->|
                   |                             |
                   |(9) ACK                      |
                   |---------------------------->|

(2) contains SDP of announcement server
(5) contains no SDP
(7) contains SDP of callee
(8) contains answer of caller for callee offer

Her, UDATE can also be used instead of Re-invites.

Method 4:

                                            Caller                        Callee
                   |                             |
                   |                             |
                   |(1) INVITE with offer        |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(2) 183 with answer 1        |
                   |<----------------------------|
                   |                             |
                   |                             |
                   |(3) PRACK                    |
                   |---------------------------->|
                   |                             |
                   |                             |
                   |(4) 200 PRACK                |
                   |<----------------------------|
                   |(5) UPDATE (callee offer)    |
                   |<----------------------------|
                   |                             |
                   |(6) 200 UPDATE (answer)      |
                   |---------------------------->|
                   |                             |
                   |(7) 200 INVITE                     |
                   |---------------------------->|
                   |                             |
                   |(8) ACK                      |
                   |---------------------------->|


In this case, when callee answers, UPDATE is sent to caller to negoitate audio with caller, and then 200 OK is sent for the initial INVITE.

Regards,
Udit --=_alternative 00366597652571FB_=-- --===============0189786755== 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 --===============0189786755==-- From sip-bounces@ietf.org Mon Oct 02 06:41:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULCD-0001a3-UN; Mon, 02 Oct 2006 06:38:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULCB-0001Rv-C5 for sip@ietf.org; Mon, 02 Oct 2006 06:38:47 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUL7r-00041d-Ik for sip@ietf.org; Mon, 02 Oct 2006 06:34:20 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 5260913F65A; Mon, 2 Oct 2006 13:34:13 +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 (anneal193.gprs.dnafinland.fi [62.78.105.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id B9EBC13F635; Mon, 2 Oct 2006 13:34:07 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 68258F0257; Mon, 2 Oct 2006 13:34:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17696.60232.366025.243192@rautu.tutpro.com> Date: Mon, 2 Oct 2006 13:34:48 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Escaping rules of SIP-URI userpart In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59403CC27EA@esealmw113.eemea.ericsson.se> References: <1ECE0EB50388174790F9694F77522CCF0D58BBC2@zrc2hxm0.corp.nortel.com> <5EB80D22825EEE42872083AD5BFFB59403CC27EA@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: "Jesske, R" , sip@ietf.org, 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 Christer Holmberg (JO/LMF) writes: > So, you could have something like: > sip:*21*12345#;phone-context=operator.com@operator.com # at the end is useless, because we know when the dial string ends anyway. -- 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 Mon Oct 02 06:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULD5-0003Ax-Gm; Mon, 02 Oct 2006 06:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULD4-00037J-3x for sip@ietf.org; Mon, 02 Oct 2006 06:39:42 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKzC-0007ds-CC for sip@ietf.org; Mon, 02 Oct 2006 06:25:23 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B302B4F011C; Mon, 2 Oct 2006 12:25:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:58:58 +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] Escaping rules of SIP-URI userpart Date: Mon, 2 Oct 2006 11:58:56 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403CC27EA@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D58BBC2@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Escaping rules of SIP-URI userpart Thread-Index: AcbkItqn8jztxEpHSY+Zb/SKvr4qRQAAKqyAAHkD4NA= From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Jeroen van Bemmel" , "Juha Heinanen" X-OriginalArrivalTime: 02 Oct 2006 09:58:58.0121 (UTC) FILETIME=[60E2D390:01C6E609] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: "Jesske, R" , 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 Francois, RFC 3966 does define a local number, and I have never seen any rule saying that you wouldn't be allowed to use it with SIP (either as a TEL-URI, or a SIP-URI with user=3Dphone). The phone-context parameter is then used to indicate the "scope" of the number. So, you could have something like: sip:*21*12345#;phone-context=3Doperator.com@operator.com And, there are people/groups that do want to use local numbers (as defined for RFC 3966) both for service codes, other local numbers etc. Regards, Christer =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 30. syyskuuta 2006 3:10 > To: Jeroen van Bemmel; Juha Heinanen > Cc: Jesske, R; sip@ietf.org; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Escaping rules of SIP-URI userpart >=20 > It's a valid URI, yes, not necessarily a valid phone number. >=20 > Certainly not a valid global phone number. >=20 > The specific example mentioned (privacy=3Don) is very broken=20 > since it really won't give you privacy at all.=20 >=20 > What bothers me with this thread is not that people want to=20 > use strange characters in URIs. >=20 > What bothers me is that people want to use it to replicate=20 > analog telephone keypad codes, the same way it was done back=20 > then, in SIP. It was broken then, and it is even more broken=20 > now that addresses are supposed to be global. >=20 > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Friday, September 29, 2006 4:56 PM > > To: Audet, Francois (SC100:3055); Juha Heinanen > > Cc: Jesske, R; sip@ietf.org; Christer Holmberg (JO/LMF) > > Subject: Re: [Sip] Escaping rules of SIP-URI userpart > >=20 > > Francois, > >=20 > > As long as one adheres to the escaping rules, it is=20 > perfectly valid to=20 > > use # in URIs. The UA should not attempt any interpretation, but=20 > > simply escape-and-pass anything the user dials. > >=20 > > The UA user interface can be such that '#' means end-of-input (ie=20 > > ), but it is also valid on the wire (when escaped) > >=20 > > Regards, > >=20 > > jeroen > >=20 > > ----- Original Message ----- > > From: "Francois Audet" > > To: "Juha Heinanen" > > Cc: "Jesske, R" ; ; "Christer=20 > > Holmberg (JO/LMF)" > > Sent: Saturday, September 30, 2006 1:25 AM > > Subject: RE: [Sip] Escaping rules of SIP-URI userpart > >=20 > >=20 > >=20 > >=20 > > Francois Audet writes: > > > > > > > There is no need for this in a URI. The service code > > should be > > > > translatable by the phone to a real URI that actually means >=20 > > > something. > > > > > > i don't understand what you are trying to say. #31# prefix > > of phone > > > number, for example, means something to PSTN and needs to > > be carried > > > there from the SIP phone, which cannot have a clue of=20 > various PSTN=20 > > > dial string conventions. or can you explain what kind of magic=20 > > > translation nortel SIP phones do when user dial #31#=20 > followed by a=20 > > > phone number? > >=20 > > I'm saying doing what you are proposing, i.e., using # in a phone=20 > > number ON THE WIRE (I.e., in a URI), is an extremely bad=20 > idea that we=20 > > shouldn't attempt to do in SIP. And it won't work except in=20 > isolated=20 > > proprietary implementations. > >=20 > > In the example you gave (I'm hearing that some network operator is=20 > > using this for privacy). > >=20 > > What you need to do is intercept the digit pattern in the=20 > phone, make=20 > > the call to the destination without the proprietary digits,=20 > and then=20 > > mark your From header as anonymous@anonymous.invalid. > >=20 > > To do it your way would MANDATE a B2BUA since my proxy=20 > would have to=20 > > remove the From and replace it (making it a B2BUA). > > And it would magically have to understand all the dialling plans in=20 > > the universe. > >=20 > > So publishing a URI with a # means most people won't be=20 > able to reach=20 > > it. #31# means absolutely nothing to me in North America.=20 > If I try to=20 > > call you with this, it just won't work. > >=20 > > As a side note, on many phones, "#" means end-of-dialling. > > It stops digit collection. And it is NOT transmitted on the wire. > >=20 > >=20 > >=20 > >=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 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 Mon Oct 02 06:42:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULEM-0004Mc-9Q; Mon, 02 Oct 2006 06:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULD8-00037J-RR for sip@ietf.org; Mon, 02 Oct 2006 06:39:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKyP-0006mm-Vb for sip@ietf.org; Mon, 02 Oct 2006 06:24:40 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EEAA44F0185; Mon, 2 Oct 2006 12:24:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:58: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Escaping rules of SIP-URI userpart Date: Mon, 2 Oct 2006 11:58:48 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403CC27E7@esealmw113.eemea.ericsson.se> In-Reply-To: <13D1EAB852BE194C94773A947138483D026D99D7@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Escaping rules of SIP-URI userpart Thread-Index: AcbjMybUD7Kg0BXTTyCCC9LTsXyD2QAgI0JgAABy70AAEHIvcAA1lDjQAE7X2GA= From: "Christer Holmberg \(JO/LMF\)" To: "Hector Morales \(hemorale\)" , "Francois Audet" , "Jesske, R" , , X-OriginalArrivalTime: 02 Oct 2006 09:58:50.0286 (UTC) FILETIME=[5C374CE0:01C6E609] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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,=20 >What I have seen in many implementations is that the # is=20 >part of the SIP URI userpart, when there is a B2BUA that has=20 >to activate or deactivate a service like the ones mentioned=20 >in the thread. It could be a B2BUA, or an application server. >The question would be if this is a valid usage on such implementations Well, that was not my original question :) Because, I have not seen = anywhere any rule that would forbid this. My question was whether it would be possible to use "#" unescapted in a = SIP-URI, since it would e.g speed up parsing, and mapping from TEL-URI = (where # IS allowed unescaped) to SIP-URI without having to first search = the the TEL-URI for a # character and escape it. Regards, Christer > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Friday, September 29, 2006 1:47 PM > To: Christer Holmberg (JO/LMF); Jesske, R;=20 > Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Escaping rules of SIP-URI userpart >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, September 29, 2006 3:55 AM > > To: Jesske, R; Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Escaping rules of SIP-URI userpart > >=20 > >=20 > > Hi Roland, > >=20 > > >I really confused about this discussion regarding'#'. > > >The range of a telephone number Digit is 0,1,2...9,A,B,C,D,F > > as far as > > >I know (it's a binary 4 Digit code ). > > >You can look in Q.764 which of the digits are used for=20 > what and also > > >E.164 gives a guideline. > > >=20 > > >So for what Telephone application '#' is used? > >=20 > > You can use if for service codes. *21#3455 > >=20 > > ...or something like that. >=20 > There is no need for this in a URI. The service code should=20 > be translatable by the phone to a real URI that actually=20 > means something. > =20 > > ...or "Please enter your pin code, followed by #". >=20 > That's not a phone number: it's dialled digits, and it is=20 > coverered by KPML and RFC 2833. It has no place in a URI. >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Gesendet: Donnerstag, 28. September 2006 21:17 > > > > An: Dale.Worley@comcast.net; sip@ietf.org > > > > Betreff: RE: [Sip] Escaping rules of SIP-URI userpart > > > >=20 > > > >=20 > > > > =20 > > > > Also, I don't think that the RFC 3261 ABNF even allows for > > > the usage > > > > of "#" as a delimiter, as defned in RFC2396. > > > >=20 > > > > Chapter 4 of RFC2396 says: > > > >=20 > > > > URI-reference =3D [ absoluteURI | relativeURI ] [ "#" fragment ] > > > >=20 > > > > First, we can see that the fragment part cannot be within > > > the URI, it > > > > optionally follows the URI > > > >=20 > > > > Second, we can see that the fragment is not part of the > > URI, it is > > > > part of URI-reference. > > > >=20 > > > > Third, there is no mentioning of URI-reference in the SIP ABNF. > > > >=20 > > > >=20 > > > > For example, the Request-URI is defined as:=20 > > > >=20 > > > > Request-URI =3D SIP-URI / SIPS-URI / absoluteURI > > > >=20 > > > > But, nowhere is ["#" fragment] mentioned.=20 > > > >=20 > > > > So, I doubt that many parsers implemented based on the SIP > > > ABNF would > > > > even accept a URI followed by a fragment in a SIP message. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF)=20 > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 28. syyskuuta 2006 19:03 > > > > > To: Dale.Worley@comcast.net; sip@ietf.org > > > > > Subject: VS: [Sip] Escaping rules of SIP-URI userpart > > > > >=20 > > > > > Hi Dale, > > > > >=20 > > > > >=20 > > > > > > The issue is that I don't understand why that rule is > > > > > needed. User=3Dphone > > > > > > means that the userpart shall be parsed as a > > > > > telephone-subscriber, and > > > > > > within a telephone-subscriber the "#" does not have any > > > > > special meaning, > > > > > > so there is no need to escape it. > > > > > > > > > > > > So, yes, you probably have to go with: > > > > > > > > > > > > sip:003%23xyz@hello.com > > > > > > > > > > > > But, I see no reason why you should have to go with: > > > > > > > > > > > > sip:003%23xyz@hello.com;user=3Dphone > > > > > > > > > > > > Instead you could use: > > > > > > > > > > > > sip:003#xyz@hello.com;user=3Dphone > > > > > > > > > > > How would you write a left-to-right parser that could cope > > > > with that? > > > > >=20 > > > > > [CHH] Well, you can't really perform a detailed parse of the=20 > > > > > userpart before you have parsed the user parameter anyway. > > > > > =20 > > > > > And, whatever the value of the user parameter is, I have > > > never seen > > > > > "#" used as this kind of delmiter in a SIP-URI anyway... > > > > > =20 > > > > > Regards, > > > > > =20 > > > > > Christer > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > =20 > > > > >=20 > > > > >=20 > > > > > Dale > > > > >=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=20 > 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 > > > > > sipping@ietf.org for new developments on the=20 > 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=20 > 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=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 Mon Oct 02 06:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULG4-00060K-MN; Mon, 02 Oct 2006 06:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULG2-0005yE-6Q for sip@ietf.org; Mon, 02 Oct 2006 06:42:46 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GULFv-0006oC-Gz for sip@ietf.org; Mon, 02 Oct 2006 06:42:46 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D26DD4F0112; Mon, 2 Oct 2006 12:42:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 11:58:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: VS: [Sip] Escaping rules of SIP-URI userpart Date: Mon, 2 Oct 2006 11:58:58 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403CC27EB@esealmw113.eemea.ericsson.se> In-Reply-To: <451DA002.8060704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [Sip] Escaping rules of SIP-URI userpart Thread-Index: AcbkF8SSOhrR98cKSnWI/jUfxTtyUAB71VKQ From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 02 Oct 2006 09:58:59.0145 (UTC) FILETIME=[617F1390:01C6E609] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: Bob Penfield , sip@ietf.org, Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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,=20 >I'm speculating here, but perhaps AbsoluteURIs are forbidden from having unescaped # so that a URI-reference, with its use of #, can be unambiguously=20 >parsed. Yes, that is probably the reason. But, since you can't use a URI-reference together with a URI in a SIP message anyway (the SIP ABNF does not allow it), my proposal is that we would allow the usage of #. Regards. Christer > Christer Holmberg (JO/LMF) wrote: > > Hi Jonathan, > >=20 > > No matter what people have implemented, the SIP ABNF does not allow=20 > > the fragment. The SIP-URI does not allow the fragment. > >=20 > > Regards, > >=20 > > Christer > > =20 > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: 29. syyskuuta 2006 0:50 > >> To: Bob Penfield > >> Cc: Christer Holmberg (JO/LMF); Juha Heinanen;=20 > >> Dale.Worley@comcast.net; sip@ietf.org > >> Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart > >> > >> I agree here with Bob, Dale and others. The SIP URI is=20 > derived from=20 > >> RFC > >> 2396 and inherits its constraints. That is part of the=20 > cost of being=20 > >> a URI as opposed to a SIP-specific type of identifier.=20 > Just because=20 > >> some implementations have not followed the spec on this point does=20 > >> not change what the spec says or why its there. > >> > >> -Jonathan R. > >> > >> Bob Penfield wrote: > >> > >>> True, but if the SIP-URI is held in a place where a > >> URI-reference is > >>> allowed, everything after the # would be interpreted as a=20 > fragment.=20 > >>> That is why 2396 indicates it needs to be escaped. > >>> > >>> cheers, > >>> (-:bob > >>> > >>> Robert F. Penfield > >>> Chief Software Architect > >>> Acme Packet, Inc. > >>> 71 Third Avenue > >>> Burlington, MA 01803 > >>> bpenfield@acmepacket.com > >>> > >>> ----- Original Message ----- From: "Christer Holmberg (JO/LMF)"=20 > >>> > >>> To: "Bob Penfield" ; "Juha Heinanen"=20 > >>> ; > >>> Cc: > >>> Sent: Thursday, September 28, 2006 3:28 PM > >>> Subject: RE: VS: [Sip] Escaping rules of SIP-URI userpart > >>> > >>> > >>> > >>> Hi, > >>> > >>> Again, when I read the SIP ABNF the only URIs that can be=20 > used are=20 > >>> absoluteURI, and of course SIP-URI, and none of these contain the=20 > >>> optional fragment part. > >>> > >>> So, instead of: > >>> > >>> Request-URI =3D SIP-URI / SIPS-URI / absoluteURI > >>> > >>> ...the ABNF should have said something like: > >>> > >>> Request-URI =3D ((SIP-URI / SIPS-URI)["#" fragment]) /=20 > >> URI-reference) > >>> ...or something like that. > >>> > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>>> -----Original Message----- > >>>> From: Bob Penfield [mailto:BPenfield@acmepacket.com] > >>>> Sent: 28. syyskuuta 2006 22:10 > >>>> To: Juha Heinanen; Dale.Worley@comcast.net > >>>> Cc: sip@ietf.org > >>>> Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart > >>>> > >>>> I suspect it might be because a SIP-URI could be placed=20 > elsewhere,=20 > >>>> like on some web page or in some other application that=20 > parses all=20 > >>>> URIs according to RFC 2396. Such a generic URI parser > >> would interpret > >>>> everything after the '#' > >>>> as a fragment. This would result in a mis-interpretation > >> of the URI. > >>>> cheers, > >>>> (-:bob > >>>> > >>>> Robert F. Penfield > >>>> Chief Software Architect > >>>> Acme Packet, Inc. > >>>> 71 Third Avenue > >>>> Burlington, MA 01803 > >>>> bpenfield@acmepacket.com > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: "Juha Heinanen" > >>>> To: > >>>> Cc: > >>>> Sent: Thursday, September 28, 2006 2:08 PM > >>>> Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart > >>>> > >>>> > >>>>> Dale.Worley@comcast.net writes: > >>>>> > >>>>>> Whether it has any use in a SIP URI is not particularly > >>>> important -- > >>>>>> as a URI it has to follow the generic syntax of URIs, RFC > >>>> 2396. And > >>>>>> RFC 2396 reserves the use of '#' for fragment identifiers. > >>>>> there are various exceptions in rfc3261 regarding other > >>>> standards that > >>>>> rfc3261 uses. why can't there be an exception on # too? > >>>>> > >>>>> -- juha > >>>>> > >>>>> _______________________________________________ > >>>>> 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=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=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: =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 >=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 Oct 02 07:09:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULcs-0005C4-I8; Mon, 02 Oct 2006 07:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULcq-0004tB-Kk for sip@ietf.org; Mon, 02 Oct 2006 07:06:20 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GULcp-0006vw-9Y for sip@ietf.org; Mon, 02 Oct 2006 07:06:20 -0400 Received: by tutpro.com (Postfix, from userid 65534) id D508D13F65A; Mon, 2 Oct 2006 14:06:08 +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 (anneal193.gprs.dnafinland.fi [62.78.105.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id C7D5413F635; Mon, 2 Oct 2006 14:05:58 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 98519F0257; Mon, 2 Oct 2006 14:06:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17696.62145.560207.145984@rautu.tutpro.com> Date: Mon, 2 Oct 2006 14:06:41 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: VS: [Sip] Escaping rules of SIP-URI userpart In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59403CC27EB@esealmw113.eemea.ericsson.se> References: <451DA002.8060704@cisco.com> <5EB80D22825EEE42872083AD5BFFB59403CC27EB@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Bob Penfield , sip@ietf.org, 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 perhaps the best solution is to get rid of URIs as sip addresses altogether and switch to JIDs. they allow # character and also support internationalized addresses. also mapping between sip and xmpp would be easier. -- 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 Mon Oct 02 07:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULwo-0002hQ-Iq; Mon, 02 Oct 2006 07:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GULwm-0002hJ-Ey for sip@ietf.org; Mon, 02 Oct 2006 07:26:56 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GULwj-0002Bm-L5 for sip@ietf.org; Mon, 02 Oct 2006 07:26:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k92BQoPe013230; Mon, 2 Oct 2006 14:26:52 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 14:26:29 +0300 Received: from [172.21.36.67] ([172.21.36.67]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 2 Oct 2006 14:26:29 +0300 Message-ID: <4520F763.6000108@nokia.com> Date: Mon, 02 Oct 2006 14:26:27 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: "ext Vrancken, Johnny" Subject: Re: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-01 References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 X-OriginalArrivalTime: 02 Oct 2006 11:26:29.0120 (UTC) FILETIME=[9AB9B000:01C6E615] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext12.nokia.com id k92BQoPe013230 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 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 ext Vrancken, Johnny kirjoitti: > What you're suggesting is that the notifier sends no body at all. I=20 > think that might not work, as some UAs might reject a NOTIFY that has > no body (as it's supposed to always have one). >=20 > [Johnny] This problem also has popped up in OMA-PAG interoperability > tests. RFC3265 states that there could be empty NOTIFY messages > (section 3.1.6.2), so UA's should/must be prepared to receive a > NOTIFY request without a body. I think a body in a NOTIFY request is > only required, if you have to convey information that is not > contained in the NOTIFY request headers. The new > Suppress-Body-If-Match header you introduced may result in NOTIFY > request without a body, isn't it? Here's the relevant thread where this was discussed a while ago, and to which I was referring: http://www1.ietf.org/mail-archive/web/simple/current/msg04057.html > Considering the descriptions of Content-Length (=C2=A720.14) and > Content-Type (=C2=A720.15) in RFC 3261: * "the Content-Length header MU= ST > be set to zero if no body is present in a message." * "the > Content-Type header MUST be present if the body is not empty", hence > there is not a MUST for the cases where the body is empty. Moreover, > in RFC3265 (section 7.1) the Content-Type header for NOTIFYs has a > "*", meaning (according to RFC 3261 section 20) that "the header > field is required if the message body is not empty". Yup, but as the thread above also points out, section 20.15. says: > The Content-Type header field MUST be present if > the body is not empty. If the body is empty, and a Content-Type > header field is present, it indicates that the body of the specific > type has zero length (for example, an empty audio file). That said, however, I'm not sure whether suppressing the body of a NOTIFY actually constitutes such a content/no-content choice. Basically, I could go either way on this, i.e., null body (Content-Type but zero-length) or no body at all (no Content-Type, zero-length). Any other opinions? >> PAGE 9: "and entity-tag in RFC3265" COMMENT: entity-tag is defined >> in RFC3903 >>=20 >> PAGE 9: Grammar COMMENT: the syntax of the new header allows a >> subscriber to supply only a single entity-tag value. The syntax of >> similar header fields for conditional requests in RFC2616 >> (If-Match, If-None-Match) allows to provide multiple entity-tag >> values for these headers. >=20 > True, but the grammar for these only allows a single entity-tag.=20 > [Johnny] I assume you want to say that in the current version of your > document the Suppress-Body-If-Match and Suppress-Notify-If-Match > header only allow to provide a single entity-tag. Right. >> Therefore, it can be considered to allow multiple entity-tag values >> for the new Suppress-Body-If-Match header. If there is a match, the >> NOTIFY request will contain the entity-tag of the resource state >> that is valid. Allowing multiple entity-tag values for the >> Suppress-Notify-If-Match header is not meaningful, as the >> subscriber, in case of a match, does not receive information >> (NOTIFY request) about which one of entity-tags is valid. >=20 > I'm not sure if you're arguing for or against having multiple=20 > entity-tags in these fields. >=20 > [Johnny]I'm arguing for having multiple entity-tags for the > Suppress-Body-If-Match header, merely to have a syntax similar to > If-Match and If-None-Match in RFC2616.=20 But that link was already broken in RFC3903, where entity-tag is specified. In hindsight, we probably would have been better off inventing a new name, like event-tag. Just to avoid the confusion... > You mentioned that optionally > the notifier could keep record in a journal of recent resource states > and their associated entity tags. The subscriber could do the same. A > use case that crosses my mind is an RLS server that makes back-end > subscriptions of behalf of different watchers to the same resource. > Hence, the RLS server may have stored multiple entity-tags (and > associated state information) for this resource. When the RLS server > sends a back-end SUBSCRIBE request for a resource, it could supply > e.g. the most recently received entity-tags pertaining to this > resource. But if you decide to allow only a single entity-tag for the > Suppress-Body-If-Match header, I will not be disappointed. I would think that the RLS aggregates resource state it receives via the backend subscriptions. For instance, even if there are n buddies watching M, the RLS only makes a single backend subscription to M. In turn, each of n would get a unique entity-tag that points to some aggregate set of resource states; these sets would probably often not be a proper subset of each other (I don't have myself on my buddy list, but most people on my buddy list have me as their buddy). So I still don't quite see how juggling with multiple entity-tags in the backend would work. > As entity-tags in SIP events are always tied to a subscription > anyway, there's no use-case I came up with that would actually make > use of more than a single entity-tag. Similarly, I dropped the notion > of weak entity tags, as they are a contentious issue even in HTTP and > I had absolutely no idea how they would work in SIP. [Johnny]When you > state "As entity-tags in SIP events are always tied to a > subscription", do you mean subscription in general or a particular > subscription? As I understood it, an entity-tag uniquely > references/identifies a particular resource state in a subscriber / > notifier information exchange. I mean, there is only ever a one-to-one relationship between an entity-tag and a subscription. In other words, you never juggle with more than one etag per a given {dialog, event, id} tuple (or did I miss some?) ;-) >> General COMMENT: Applicability of the ETag mechanism for resoure >> list subscriptions. The document focuses on an ETag mechanism for >> subscriptions targeted on a single resource. However, one can also >> subscribe for a resource list (RFC4662). In that case, the >> resulting NOTIFY requests comprise the resource state of no / one / >> multiple resources in addition to Resource List Meta Information >> (RLMI) pertaining to the resource list subscription. This RLMI >> information contains information about the individual resources and >> the status of the virtual subscriptions. Your document preferably >> should include a statement about the applicability of the ETag >> mechanism for resource list subscriptions. You may either state >> that 1. it is out of scope of the document 2. the mechanism also >> can be applied to resource list subscriptions. In that case you >> need to clearly specify what the ETag represents (e.g. does it also >> include the full RLMI information ?) 3. you could consider to >> exchange a set of ETags, one for each resource in the list. In the >> NOTIFY request, these ETags can be included in the RLMI information >> but for the SUBSCRIBE request a new mechanism is to be introduced >> to exchange the ETags of the individual resources. >=20 > I think this mechanism applies to resource-list subscriptions=20 > out-of-the-box, as it should to any type of subscriptions. The etags=20 > work on the level of subscriptions, and really don't care what event=20 > package is carried on top. [Johnny]I don't get your point. I agree > that the etag mechanism works for any event package. >=20 > Can you elaborate why there would need to be a need for additional=20 > specification? [Johnny] Suppose you are polling the event state of a > resource list. The resulting NOTIFY request contains an etag, RLMI > information about the N resources in the list (resource info, info on > the back-end subscriptions), and the resource state of M resources > for which successfully a back-end subscription was made. Suppose that > in a subsequent poll for the same resource list, the resource state > of the same M resources has not changed but some RLMI information has > changed, e.g. - information about a resource in the resource list has > changed - information about a back-end subscription has changed - a > resource is added / deleted, for which for whatever reason no > resource state is notified Does the notifier generated local entity > tag and the subscriber provided etag match in this case? I would say yes, the etag would change, since the RLMI is also part of the state. > In the above resource list polling example and assuming that a single > entity tag is used for the whole resource list, ALL M resource > states are to be included in the resulting NOTIFY request if there is > a change in ONE of the resource states. If entity tags per resource > were conveyed, then only the resource state of the resources that > actually have changed would have to be notified. Please note that > usage of a set of Etags (one per resource) in case of a resource list > subscription is just a suggestion, nothing more. I'm not sure I'm convinced on the idea of multiple etags. To me, it seems logical to have whatever the event package considers full state (here, it would be resource state plus meta-info) be identifiable by a single etag. 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 Mon Oct 02 07:40:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUM7Y-0000QZ-6I; Mon, 02 Oct 2006 07:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUM7W-0000HQ-9p for sip@ietf.org; Mon, 02 Oct 2006 07:38:02 -0400 Received: from web52807.mail.yahoo.com ([206.190.48.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUM7U-00058w-Uv for sip@ietf.org; Mon, 02 Oct 2006 07:38:02 -0400 Received: (qmail 9797 invoked by uid 60001); 2 Oct 2006 11:38:00 -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=nj+4cHgitHP27GpknQg1SF13BzRllelcD436csOIX4JJfnZvlxu/qYfpxtoNHbubXQvKzB0Nym1+PqL/U2vegl7n3tBoIuH+J9/gSvcJm96mlRdOvUYHINQAHx30JyD1CuSGDWfgn+QLF/xIfT8XcMZz9nhKbnwwJzS4C9OCTPU= ; Message-ID: <20061002113800.9794.qmail@web52807.mail.yahoo.com> Received: from [47.165.147.37] by web52807.mail.yahoo.com via HTTP; Mon, 02 Oct 2006 04:38:00 PDT Date: Mon, 2 Oct 2006 04:38:00 -0700 (PDT) From: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= Subject: Re: AW: [Sip] Escaping rules of SIP-URI userpart To: Dale.Worley@comcast.net, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 you can check-out Q763 for SAM usage with IAM for the last paragraph Dale i= ndicated however this partial dialed user mentality has no equivalency in s= ip afaik.=0A=0A=0A----- Original Message ----=0AFrom: "Dale.Worley@comcast.= net" =0ATo: sip@ietf.org=0ASent: Friday, September= 29, 2006 3:15:38 PM=0ASubject: Re: AW: [Sip] Escaping rules of SIP-URI use= rpart=0A=0A=0AFrom: "Jesske, R" =0A=0A I really confu= sed about this discussion regarding'#'.=0A The range of a telephone numbe= r Digit is 0,1,2...9,A,B,C,D,F as far=0A as I know (it's a binary 4 Digit= code ).=0A You can look in Q.764 which of the digits are used for what a= nd=0A also E.164 gives a guideline.=0A=0A So for what Telephone applica= tion '#' is used?=0A=0AThe real table of DTMF digits, laid out according to= the organization=0Aof the *dual tones*, is:=0A=0A 1 2 3 A=0A=0A 4 5 = 6 B=0A=0A 7 8 9 C=0A=0A * 0 # D=0A=0Abut most keypads don't have the = right-hand column.=0A=0AYou can also see "*" and "#" in the RTP encoding ch= art, RFC 2833=0Asection 3.10.=0A=0A"*" and "#" are used for invoking specia= l features in many phone=0Asystems. (E.g., in sipX, "*78" is the default c= all pick-up code, and=0A"*4" the default call retrieval code.)=0A=0AAlso, w= hen dialing calls for which the central office doesn't have=0Aknowledge of = when the dial string has ended (e.g., international=0Acalls), "#" is used a= s a signal that the dial string is finished.=0A=0ADale=0A=0A_______________= ________________________________=0ASip mailing list https://www1.ietf.org/= mailman/listinfo/sip=0AThis list is for NEW development of the core SIP Pro= tocol=0AUse sip-implementors@cs.columbia.edu for questions on current sip= =0AUse 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 Oct 02 09:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNo2-0008WI-LN; Mon, 02 Oct 2006 09:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNo1-0008Rq-8X for sip@ietf.org; Mon, 02 Oct 2006 09:26:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNnu-000145-0r for sip@ietf.org; Mon, 02 Oct 2006 09:26:01 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 32C8E4F012C; Mon, 2 Oct 2006 15:25:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 14:57:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Early media query Date: Mon, 2 Oct 2006 14:57:29 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403CC31E2@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Early media query Thread-Index: AcbmIJab3ngqkgz2T2SAYnlU+d5jbwAAUFSQ From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 02 Oct 2006 12:57:30.0675 (UTC) FILETIME=[5210D830:01C6E622] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1 Cc: sip-implementors@cs.columbia.edu X-BeenThere: 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="===============1018274490==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1018274490== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E622.51B149B6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E622.51B149B6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, =20 You can use Method 2, assuming the 18x and 200 have different To tag values. Otherwise you can use Method 3 or 4 (message 9 in Method 3, and message 7 in Method 4, seem to go in the wrong direction, though). =20 Regards, =20 Christer =20 =20 =20 =20 =20 ________________________________ From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]=20 Sent: 2. lokakuuta 2006 12:57 To: sip@ietf.org Cc: sip-implementors@cs.columbia.edu Subject: [Sip] Early media query =09 =09 Hi,=20 =09 I want to made an application where we can use early media for playing initial in-band announcements, and then finally connecting the caller to actual callee (eg prepaid card application).=20 =09 I want to know which is the correct way to support this as per SIP RFC.=20 =09 Method 1:=20 =09 =09 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) 200 OK with SDP |=20 |<----------------------------|=20 | |=20 | |=20 |(4) ACK |=20 |---------------------------->|=20 | |=20 =09 =09 (2) contains SDP of announcement server=20 (3) contains SDP of callee=20 =09 =09 Method 2:=20 =09 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 | |=20 | |=20 |(5) 200 INVITE with sdp |=20 |<----------------------------|=20 | |=20 | |=20 |(6) ACK |=20 |---------------------------->|=20 | |=20 | |=20 | |=20 | |=20 =09 (2) contains SDP of announcement server=20 (5) contains SDP of callee=20 =09 =09 Method 3:=20 =09 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 |(5) 200 OK |=20 |<----------------------------|=20 | |=20 |(6) ACK |=20 |---------------------------->|=20 | |=20 |(7)Re-INVITE with SDP |=20 |<----------------------------|=20 | |=20 | |=20 |(8) 200 OK with SDP |=20 |---------------------------->|=20 | |=20 |(9) ACK |=20 |---------------------------->|=20 =09 (2) contains SDP of announcement server=20 (5) contains no SDP=20 (7) contains SDP of callee=20 (8) contains answer of caller for callee offer=20 =09 Her, UDATE can also be used instead of Re-invites.=20 =09 Method 4:=20 =09 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 |(5) UPDATE (callee offer) |=20 |<----------------------------|=20 | |=20 |(6) 200 UPDATE (answer) |=20 |---------------------------->|=20 | |=20 |(7) 200 INVITE |=20 |---------------------------->|=20 | |=20 |(8) ACK |=20 |---------------------------->|=20 =09 =09 In this case, when callee answers, UPDATE is sent to caller to negoitate audio with caller, and then 200 OK is sent for the initial INVITE.=20 =09 Regards,=20 Udit ------_=_NextPart_001_01C6E622.51B149B6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
You=20 can use Method 2, assuming the 18x and 200 have different To tag values. = Otherwise you can use Method 3 or 4 (message 9 in Method 3, and message = 7 in=20 Method 4, seem to go in the wrong direction, = though).
 
Regards,
 
Christer
 
 
 
 
 

From: Udit_Goyal@3com.com=20 [mailto:Udit_Goyal@3com.com]
Sent: 2. lokakuuta 2006=20 12:57
To: sip@ietf.org
Cc:=20 sip-implementors@cs.columbia.edu
Subject: [Sip] Early media=20 query


Hi, =

I want to made an application where we can = use early=20 media for playing initial in-band announcements, and then finally = connecting=20 the caller to actual callee (eg prepaid card application).=20

I want to know which is the = correct way=20 to support this as per SIP RFC.

Method 1:


 =20                Caller   =  =20                  =20  Callee
  =    =20              |       =  =20                     = |=20
        =    =20        |             =  =20               |
          =    =20      |(1) INVITE with offer       =  |=20
        =    =20        |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(2) 183 with answer 1       =  |=20
        =    =20        |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(3) 200 OK with SDP        =20  |
    =    =20          =20  |<----------------------------|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |(4) ACK     =  =20                | =
          =    =20      |---------------------------->| =
          =    =20      |               =  =20             |


(2) contains SDP of announcement = server=20
(3) contains SDP of callee =


Method 2: =

            =    =20                     =  =20   Caller     =  =20                 =  Callee=20
        =    =20        |             =  =20               |
          =    =20      |               =  =20             |
          =    =20      |(1) INVITE with offer       =  |=20
        =    =20        |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(2) 183 with answer 1       =  |=20
        =    =20        |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(3) PRACK           =  =20        |
 =20                =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |(4) 200 PRACK   =  =20            |
                =  =20  |<----------------------------|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20          |
                =  =20  |(5) 200 INVITE with sdp      |
          =    =20      |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(6) ACK             =  =20        |
 =20                =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |       =  =20                     = |=20
        =    =20        |             =  =20               | =

(2) contains SDP of announcement = server=20
(5) contains SDP of callee =


Method 3: =

        Caller         =    =20            Callee
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(1) INVITE with offer       =  |=20
        =    =20        |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(2) 183 with answer 1       =  |=20
        =    =20        |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(3) PRACK           =  =20        |
 =20                =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |(4) 200 PRACK   =  =20            |
                =  =20  |<----------------------------|
                =  =20  |(5) 200 OK               =  =20   |
    =  =20            =20  |<----------------------------|
                =    |=20                     =  =20       |
 =20                  |(6) ACK =  =20                   =  |=20
        =    =20        |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |(7)Re-INVITE with SDP       =  |=20
        =    =20        |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(8) 200 OK with SDP        =20  |
    =    =20          =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |(9) ACK =  =20                   =  |=20
        =    =20        |---------------------------->|=20

(2) contains SDP of = announcement=20 server
(5) contains no = SDP=20
(7) contains SDP of callee =
(8) contains answer of caller for callee = offer=20

Her, UDATE can also be used = instead of=20 Re-invites.

Method = 4:=20

        =    =20                     =  =20           Caller               =    =20      Callee
 =20                  |   =  =20                     =  =20   |
    =  =20              |       =  =20                     = |=20
        =    =20        |(1) INVITE with offer       =  |
    =    =20          =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |(2) 183 with answer 1 =  =20      |
   =20              =20  |<----------------------------|
                =    |=20                     =  =20       |
 =20                  |   =  =20                     =  =20   |
    =  =20              |(3) PRACK   =  =20                | =
          =    =20      |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |               =  =20             |
          =    =20      |(4) 200 PRACK           =  =20    |
  =    =20            =20  |<----------------------------|
                =  =20  |(5) UPDATE (callee offer)    |
          =    =20      |<----------------------------| =
          =    =20      |               =  =20             |
          =    =20      |(6) 200 UPDATE (answer)     =  |=20
        =    =20        |---------------------------->| =
          =    =20      |               =  =20             |
          =    =20      |(7) 200 INVITE           =  =20         |
                =  =20  |---------------------------->|
                =    |=20                     =  =20       |
 =20                  |(8) ACK =  =20                   =  |=20
        =    =20        |---------------------------->|=20


In this case, when = callee=20 answers, UPDATE is sent to caller to negoitate audio with caller, and = then 200=20 OK is sent for the initial INVITE.

Regards,
Udit ------_=_NextPart_001_01C6E622.51B149B6-- --===============1018274490== 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 --===============1018274490==-- From sip-bounces@ietf.org Mon Oct 02 10:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP8B-0004ZZ-2N; Mon, 02 Oct 2006 10:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUP7t-0003yh-UG for sip@ietf.org; Mon, 02 Oct 2006 10:50:37 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUP7r-0002ud-CV for sip@ietf.org; Mon, 02 Oct 2006 10:50:37 -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 k92EoFHe016585; Mon, 2 Oct 2006 09:50:15 -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 k92EoFB23604; Mon, 2 Oct 2006 09:50:15 -0500 (CDT) Message-ID: <45212727.3080101@lucent.com> Date: Mon, 02 Oct 2006 09:50: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: Tina TSOU Subject: Re: [Sip] doubts about draft-gurbani-sip-domain-certs References: <44932C00.9010705@lucent.com> <00e801c6dc7a$5c004440$6c95460a@china.huawei.com> <45131B4F.3020409@lucent.com> <018a01c6de23$3e4e7a70$6c95460a@china.huawei.com> <4516A0E1.4050305@lucent.com> <015201c6e04b$cd12fae0$6c95460a@china.huawei.com> In-Reply-To: <015201c6e04b$cd12fae0$6c95460a@china.huawei.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: 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 Catching up on pending email ... sorry for the delay. More inline. Tina TSOU wrote: > [Tina4: In sip-sec-flow-01 section 8 Additional test scenarios, there > is only DNS label being compared. But in this draft, URI label must > be compared. This behavior is not compatible.] The intent of domain-certs is to get enough traction so we can normatively specify the behavior to be common across all drafts. > [Tina4: Perhaps I had missed some discussions on this draft about why > SIP URI label should be introduced to TLS certificate verification and > DNS label checking is not the preferred choice. Would you give me a > reference? Please see http://www3.ietf.org/proceedings/06jul/slides/sip-9.pdf, and http://www3.ietf.org/proceedings/06jul/minutes/sip.html (search for domain-certs). > This is the question which missed in the text jungle in last mail. Is > a host like multi-user computer within the scope of this draft? Yes. > One kind of attack in multi-user computer is being discussed in > connect-reuse draft section 9.3. If all the users share the same site > certificate, the same attack can happen for TLS. ] Could you please amplify on how you see the attack proceeding... 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 Oct 02 15:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTXY-0002UP-QC; Mon, 02 Oct 2006 15:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTXX-0002UK-HT for sip@ietf.org; Mon, 02 Oct 2006 15:33:23 -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 1GUTXU-0005Ua-QR for sip@ietf.org; Mon, 02 Oct 2006 15:33:23 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6I00D01WZNQG@siemenscomms.co.uk> for sip@ietf.org; Mon, 02 Oct 2006 20:33:24 +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 <0J6I00D1SWZMDF@siemenscomms.co.uk>; Mon, 02 Oct 2006 20:33:22 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SRRAD>; Mon, 02 Oct 2006 20:33:08 +0100 Content-return: allowed Date: Mon, 02 Oct 2006 20:33:05 +0100 From: "Elwell, John" To: Cullen Jennings , Jon Peterson , SIP Message-id: <50B1CBA96870A34799A506B2313F26670A0007FD@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: 410b68b37343617c6913e76d02180b14 Cc: Subject: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 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 Thinking further on this, perhaps there is a 4th way: 4. Specify that if a UAS rejects a mid-dialog request with 436, 437 or 438, then it MUST NOT invoke the verifier for a subsequent request on the same dialog unless the From header field URI has changed, and in such cases SHOULD NOT make use of the unverified connected-identity. Then a UAC, on receiving 436, 437 or 438, MUST repeat the request once. This would allow business as usual on this dialog (but without the benefit of connected identity, therefore no worse than at present). It avoids any change to RFC 4474, because verification is optional anyway. Would this work? John > -----Original Message----- > From: Elwell, John > Sent: 26 September 2006 21:02 > To: Cullen Jennings; Jon Peterson > Cc: SIP; Paul Kyzivat > Subject: FW: Rejecting connected identity (was RE: > draft-ietf-sip-connected-id entity-01 comments) > > Cullen, Jon, > > In case you missed this (it wasn't addressed directly to > you), I would greatly appreciate an opinion from each of you > on this remaining issue in connected-identity. Just to > summarise, RFC 4474 leaves it up to policy whether to return > a 428 response if Identity is missing, but mandates the > sending of a 436, 437 or 438 response for certain errors > arising while verifying the signature. It seems that for mid > dialog requests this behaviour could be harmful. What does > the UAC for the mid dialog request do if it receives 436, 437 > or 438? If the mid-dialog request was solely for the purpose > of connected identity, it can give up and allow the call to > continue as is. But if the request was for some other purpose > (e.g., renegotiating the session because of hold, say, or > session timer refresh), the UAC really wants it to work. For > the normal case where the Authentication Service is at a > proxy, not at the UAC, the UAC cannot force the > Authentication Service to refrain from putting this > unverifiable signature in the mid-dialog request, so any > attempts to repeat the request would most likely be doomed to > getting the same response. > > It seems there are three things we could do, none very attractive: > 1. Get connected-identity to modify the procedures of RFC > 4474 for a verifier by softening the requirements for sending > 436, 437 and 438 in response to mid-dialog requests. But then > a mid-dialog request from a rogue source would be accepted. > 2. Say that the Authentication Service should omit the > signing of mid-dialog requests if a previous attempt has > resulted in 436, 437 or 438. But this implies statefulness at the AS. > 3. Accept the fact the mid-dialog requests can fail in this > way and therefore things like session refresh and session > renegotiation cannot be done, probably resulting in call > failure. Sounds bad, but it is no different from an initial > INVITE request, where there is nothing the UAC can do if the > AS inserts an Identity header that gets rejected with 436, 437 or 438. > > John > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 22 September 2006 19:26 > > To: Elwell, John > > Cc: Cullen Jennings; SIP > > Subject: Re: Rejecting connected identity (was RE: > > draft-ietf-sip-connected-id entity-01 comments) > > > > John, > > > > I want to hear what others, especially Jon and Cullen, have > > to say about > > this. > > > > It is of some concern to me that a call might fail because of some > > problem with the identity mechanism when the same call might have > > succeeded in the absence of any identity. > > > > But possibly the solution to this is policy in the > > implementation of the > > verifier. What to do in the case of the conditions that > lead to these > > errors could be configurable in the verifier: either to > generate the > > error or simply to remove the identity info from the > message. And the > > policy could conceivably vary based on attributes of the > > message, such > > as whether it is in-dialog or not. > > > > Does it require a change to 4474 to permit that kind of policy? > > > > It would be annoying if the end user had no control over the > > insertion > > and verification of identity, and it resulted in calls > > failing that the > > user would like to permit. But I suppose that is itself a policy > > decision. There are certainly enterprises that want to exert > > that kind > > of control over what users are permitted to do. > > > > Paul > > > > Elwell, John wrote: > > > Paul, > > > > > > I agree with most of your points, and on reflection I think > > I agree that the > > > solution has to be with the verifier. > > > > > > I think RFC 4474 is not a problem as far as sending a 428 > > 'Use Identity > > > Header' response is concerned, because that is left to > > policy, so we could > > > say in connected-identity that policy should be to not send 428. > > > > > > However, 436, 437 and 438 responses are all a problem, > > because RFC 4474 says > > > that they MUST be sent under respective conditions. > > Interestingly, though, > > > there are other failure scenarios that can arise from the > > procedures of > > > section 6 of RFC 4474 for which no normative statement is > > given on how to > > > respond, e.g. invalid Date header field, signer not > > authoritative for the > > > domain. > > > > > > So one way to solve the present problem would be for the > > connected-identity > > > draft to modify verifier behaviour in RFC 4474 in the case > > of mid-dialog > > > requests. I guess this would mean that it would update RFC > > 4474 as well as > > > updating RFC 3261. But I don't like this, because it seems > > to remove some of > > > the security properties of RFC 4474. > > > > > > Another way would be to accept that 436, 437 and 438 > > responses will be sent, > > > and failure to verify a signature will therefore result in > > inability to > > > process the UPDATE or re-INVITE request, and hence if the > UPDATE or > > > re-INVITE request was for some other purpose such as > > session timer refresh > > > or modifying the session, that action will fail. Then the > > call will fail (in > > > the case of inability to refresh the session timer) or the session > > > modification will fail. I guess this is somewhat analogous > > to caller ID > > > verification failure in an INVITE request - it is > > impossible to establish a > > > call if verification fails. Moreover, the UAC has no > > ability to rectify the > > > situation, since it is at the mercy of a proxy-based > > Authentication Service > > > that puts a rogue Identity header field in every request. > > In the connected > > > identity case, the only difference is that the call is > > already established > > > but is likely to fail if verification fails. > > > > > > Of course, if the mid-dialog request is indeed from the > > wrong source, then > > > sending a 436, 437 or 438 response is indeed the correct > > thing to do, and > > > overriding the verification procedures of RFC 4474 would > > indeed be the wrong > > > thing to do. So perhaps we just have to accept that these > > response codes can > > > be received and will lead to failure. > > > > > > So, my preferred way forward is simply to recommend not > > sending a 428 and > > > accept the consequences of other responses that the > > verifier might send. > > > > > > John > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: 22 September 2006 15:13 > > >> To: Elwell, John > > >> Cc: Cullen Jennings; SIP > > >> Subject: Re: [Sip] RE: > > draft-ietf-sip-connected-identity-01 comments > > >> > > >> > > >> > > >> Elwell, John wrote: > > >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > > >>>> When an Update is sent. Are there any conditions under which > > >>>> it might > > >>>> be rejected. Bad identity for example. I think that > > might need a > > >>>> little discussion and also what the UA does when it sends > > >> an update > > >>>> with a no identity and it gets rejected. > > >>> [JRE] A very good point. We don't want to get to a > > >> situation where it is > > >>> impossible to perform a mid-dialog request (e.g., for > > >> purposes such as > > >>> session timer refresh or session re-negotiation) just > > >> because connected > > >>> identity fails. > > >>> My proposed fix is as follows: > > >>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > > >> with 428 'Use > > >>> Identity Header'. > > >> I'm not sure about this. At the least I think this one needs > > >> some clear > > >> explanation of the SHOULD NOT - about the conditions when > > it can be > > >> violated. > > >> > > >> I see this as somewhat analogous to doing a digest > challenge on an > > >> in-dialog request. In some cases it is the right thing to do. > > >> > > >> A UA that imposes such a requirement will be limited in what > > >> it can do, > > >> but that may still be right in some cases. > > >> > > >>> 2. Say that an Authentication Service MUST NOT add an > > >> Identity header field > > >>> to a mid-dialog request if a previous request on that > > >> dialog has resulted in > > >>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or > > >> 438 'Invalid > > >>> Identity Header'. > > >> This requirement would force the authentication service to > > be dialog > > >> stateful, which is not ideal. Better to push the state > > back into the > > >> sender of the request. This may require a way for the UAC > > to tell the > > >> authentication service not to act. > > >> > > >>> 3. Say that a UAC MUST repeat a mid-dialog request that > > >> results in one of > > >>> these responses if the mid-dialog request was not solely > > >> for the purpose of > > >>> connected identity. If solely for the purpose of connected > > >> identity there is > > >>> no point in repeating it, so I will say "SHOULD NOT take > > any further > > >>> action". > > >> This seems wrong to me. > > >> > > >> I think that the remedy to these is in the verifier. The > > >> purpose of the > > >> verifier is ultimately to drive an authorization decision. If > > >> authorization would succeed in the absence of the > > identity, then the > > >> request should be permitted to continue as if the identity > > >> was not present. > > >> > > >> Unfortunately this would seem to require a revision to 4474 > > >> even though > > >> the paint is hardly dry on it. > > >> > > >> If this is done, then there is no need of a mechanism to > cause the > > >> authentication service *not* to authenticate. If this is > > *not* done, > > >> then that need remains, which will still require a > change to 4474. > > >> > > >> 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 Oct 02 15:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTdT-0006W2-SG; Mon, 02 Oct 2006 15:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTdS-0006PY-B1 for sip@ietf.org; Mon, 02 Oct 2006 15:39:30 -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 1GUTdR-0006On-0Z for sip@ietf.org; Mon, 02 Oct 2006 15:39:30 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6I00E01XA5ZB@siemenscomms.co.uk> for sip@ietf.org; Mon, 02 Oct 2006 20:39:41 +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 <0J6I00E0HXA5Z6@siemenscomms.co.uk>; Mon, 02 Oct 2006 20:39:41 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SRRDJ>; Mon, 02 Oct 2006 20:39:27 +0100 Content-return: allowed Date: Mon, 02 Oct 2006 20:39:27 +0100 From: "Elwell, John" To: SIP , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A0007FE@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Sip] Use of Require header field in connected-identity X-BeenThere: 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="===============0554346756==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0554346756== Content-return: allowed Content-type: multipart/alternative; boundary="Boundary_(ID_HntpKFOv7MshP8cL1RiENA)" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_HntpKFOv7MshP8cL1RiENA) Content-type: text/plain Content-transfer-encoding: 7BIT During WGLC I received a comment from Paul that when sending a mid-dialog request with a changed From header field URI, we should also include a Require header field with option tag id-change. In theory it should not be needed, because the peer UA will already have indicated id-change in the Supported header field, so it is known to support the capability. Paul's rationale was to include the Require header field in case something had gone wrong. I heard no other comment in favour of or against this. My opinion is that it is unnecessary - if something of this nature has gone wrong, then it is hard to be sure that simply including the Require header field will be sufficient to avoid further problems. Furthermore, if we specify use of the Require header field, it would mean we have to specify what to do if we get back a 420. So on balance I am against making this change. Any other opinions? John --Boundary_(ID_HntpKFOv7MshP8cL1RiENA) Content-type: text/html Content-transfer-encoding: 7BIT Use of Require header field in connected-identity

During WGLC I received a comment from Paul that when sending a mid-dialog request with a changed From header field URI, we should also include a Require header field with option tag id-change. In theory it should not be needed, because the peer UA will already have indicated id-change in the Supported header field, so it is known to support the capability. Paul's rationale was to include the Require header field in case something had gone wrong.

I heard no other comment in favour of or against this. My opinion is that it is unnecessary - if something of this nature has gone wrong, then it is hard to be sure that simply including the Require header field will be sufficient to avoid further problems. Furthermore, if we specify use of the Require header field, it would mean we have to specify what to do if we get back a 420. So on balance I am against making this change.

Any other opinions?

John


--Boundary_(ID_HntpKFOv7MshP8cL1RiENA)-- --===============0554346756== 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 --===============0554346756==-- From sip-bounces@ietf.org Mon Oct 02 16:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUg7-0007Hk-Nd; Mon, 02 Oct 2006 16:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUUg6-0007Hf-FF for sip@ietf.org; Mon, 02 Oct 2006 16:46:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUUg5-00065O-6f for sip@ietf.org; Mon, 02 Oct 2006 16:46:18 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 02 Oct 2006 13:46:14 -0700 X-IronPort-AV: i="4.09,245,1157353200"; d="scan'208"; a="1856207187:sNHT46061380" 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 k92KkEDD008235; Mon, 2 Oct 2006 13:46:14 -0700 Received: from [192.168.1.3] (sjc-vpn1-804.cisco.com [10.21.99.36]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92KkCJn011584; Mon, 2 Oct 2006 13:46:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <7B050326-C7B7-4B64-930D-E0E3C3430037@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP , Rohan Mahy , Adam Roach From: Cullen Jennings Date: Mon, 2 Oct 2006 13:46:12 -0700 X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=398; t=1159821974; x=1160685974; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Outbound=20and=20SigComp; X=v=3Dcisco.com=3B=20h=3D4Fc9WENLUMZgy53GtU9xGexdNkk=3D; b=w/Z6s3SOiw+cJm7YRoUHs6Ab5IhYCajh0wreqJhkVlHMr6QQYOrU4d8c5/6TSrShCgKgUjQZ AJQI30G3SRu/uFU1CN6NgA1jnw7GjM2glrylU9hquxJNk6fTNxjgM71n; Authentication-Results: sj-dkim-2.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] Outbound and SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 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 question I have been thinking about a little ... what happens when a UA is doing both outbound and sigcomp. Is it clear enough how this happiness? Is stun inside or outside the sigcomp, etc? Anyways, I just wanted to lodge this as an open issue - we probably should check that this is reasonable clear how to do this even if we don't have to say anything about it in 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 Oct 02 17:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVbR-0004aS-Vb; Mon, 02 Oct 2006 17:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUVbP-0004aN-Qz for sip@ietf.org; Mon, 02 Oct 2006 17:45:31 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUVbN-0008Vj-I2 for sip@ietf.org; Mon, 02 Oct 2006 17:45:31 -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 k92LjPso004692 for ; Mon, 2 Oct 2006 16:45:25 -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 k92LjOB13450; Mon, 2 Oct 2006 16:45:24 -0500 (CDT) Message-ID: <45218874.3090208@lucent.com> Date: Mon, 02 Oct 2006 16:45:24 -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: 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Sip] Feedback solicited on domain-certs-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 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: In preparation for the upcoming IETF, we will like to solicit feedback from the WG on domain-certs-03: http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-03.txt This draft is the distillation of the discussion we had in Montreal. It posits that the certificates contain two identities: one for the transport layer and one for the application layer. The reasons for these is provided in the draft. There has been some discussion on the WG, but we believe that the general direction of the draft will benefit from more WG discussion. Could you kindly spare a few minutes to read the draft and post feedback in preparation for the next revision. 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 Oct 02 18:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWSl-0002B7-H8; Mon, 02 Oct 2006 18:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWSj-00029u-MY for sip@ietf.org; Mon, 02 Oct 2006 18:40:37 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWR0-00078J-K0 for sip@ietf.org; Mon, 02 Oct 2006 18:38:51 -0400 Received: (qmail 16292 invoked by uid 0); 2 Oct 2006 22:38:36 -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 < >; 2 Oct 2006 22:38:36 -0000 Message-ID: <009b01c6e673$86e2dd00$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Hector Morales \(hemorale\)" , "Francois Audet" , "Jesske, R" , , References: <5EB80D22825EEE42872083AD5BFFB59403CC27E7@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Escaping rules of SIP-URI userpart Date: Tue, 3 Oct 2006 00:38:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: 6a45e05c1e4343200aa6b327df2c43fc 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: "Christer Holmberg (JO/LMF)" To: "Hector Morales (hemorale)" ; "Francois Audet" ; "Jesske, R" ; ; Sent: Monday, October 02, 2006 11:58 AM Subject: RE: [Sip] Escaping rules of SIP-URI userpart Hi, >What I have seen in many implementations is that the # is >part of the SIP URI userpart, when there is a B2BUA that has >to activate or deactivate a service like the ones mentioned >in the thread. It could be a B2BUA, or an application server. >The question would be if this is a valid usage on such implementations Well, that was not my original question :) Because, I have not seen anywhere any rule that would forbid this. My question was whether it would be possible to use "#" unescapted in a SIP-URI, since it would e.g speed up parsing, and mapping from TEL-URI (where # IS allowed unescaped) to SIP-URI without having to first search the the TEL-URI for a # character and escape it. Regards, Christer > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Friday, September 29, 2006 1:47 PM > To: Christer Holmberg (JO/LMF); Jesske, R; > Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Escaping rules of SIP-URI userpart > > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, September 29, 2006 3:55 AM > > To: Jesske, R; Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Escaping rules of SIP-URI userpart > > > > > > Hi Roland, > > > > >I really confused about this discussion regarding'#'. > > >The range of a telephone number Digit is 0,1,2...9,A,B,C,D,F > > as far as > > >I know (it's a binary 4 Digit code ). > > >You can look in Q.764 which of the digits are used for > what and also > > >E.164 gives a guideline. > > > > > >So for what Telephone application '#' is used? > > > > You can use if for service codes. *21#3455 > > > > ...or something like that. > > There is no need for this in a URI. The service code should > be translatable by the phone to a real URI that actually > means something. > > > ...or "Please enter your pin code, followed by #". > > That's not a phone number: it's dialled digits, and it is > coverered by KPML and RFC 2833. It has no place in a URI. > > > Regards, > > > > Christer > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Gesendet: Donnerstag, 28. September 2006 21:17 > > > > An: Dale.Worley@comcast.net; sip@ietf.org > > > > Betreff: RE: [Sip] Escaping rules of SIP-URI userpart > > > > > > > > > > > > > > > > Also, I don't think that the RFC 3261 ABNF even allows for > > > the usage > > > > of "#" as a delimiter, as defned in RFC2396. > > > > > > > > Chapter 4 of RFC2396 says: > > > > > > > > URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] > > > > > > > > First, we can see that the fragment part cannot be within > > > the URI, it > > > > optionally follows the URI > > > > > > > > Second, we can see that the fragment is not part of the > > URI, it is > > > > part of URI-reference. > > > > > > > > Third, there is no mentioning of URI-reference in the SIP ABNF. > > > > > > > > > > > > For example, the Request-URI is defined as: > > > > > > > > Request-URI = SIP-URI / SIPS-URI / absoluteURI > > > > > > > > But, nowhere is ["#" fragment] mentioned. > > > > > > > > So, I doubt that many parsers implemented based on the SIP > > > ABNF would > > > > even accept a URI followed by a fragment in a SIP message. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF) > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 28. syyskuuta 2006 19:03 > > > > > To: Dale.Worley@comcast.net; sip@ietf.org > > > > > Subject: VS: [Sip] Escaping rules of SIP-URI userpart > > > > > > > > > > Hi Dale, > > > > > > > > > > > > > > > > The issue is that I don't understand why that rule is > > > > > needed. User=phone > > > > > > means that the userpart shall be parsed as a > > > > > telephone-subscriber, and > > > > > > within a telephone-subscriber the "#" does not have any > > > > > special meaning, > > > > > > so there is no need to escape it. > > > > > > > > > > > > So, yes, you probably have to go with: > > > > > > > > > > > > sip:003%23xyz@hello.com > > > > > > > > > > > > But, I see no reason why you should have to go with: > > > > > > > > > > > > sip:003%23xyz@hello.com;user=phone > > > > > > > > > > > > Instead you could use: > > > > > > > > > > > > sip:003#xyz@hello.com;user=phone > > > > > > > > > > > How would you write a left-to-right parser that could cope > > > > with that? > > > > > > > > > > [CHH] Well, you can't really perform a detailed parse of the > > > > > userpart before you have parsed the user parameter anyway. > > > > > > > > > > And, whatever the value of the user parameter is, I have > > > never seen > > > > > "#" used as this kind of delmiter in a SIP-URI anyway... > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP 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 Mon Oct 02 18:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWYw-0001Rm-Em; Mon, 02 Oct 2006 18:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWYu-0001Rg-QI for sip@ietf.org; Mon, 02 Oct 2006 18:47:00 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWYt-0000sA-Ds for sip@ietf.org; Mon, 02 Oct 2006 18:47:00 -0400 Received: (qmail 21688 invoked by uid 0); 2 Oct 2006 22:46:46 -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 < >; 2 Oct 2006 22:46:46 -0000 Message-ID: <00a001c6e674$aaf7a8f0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Hector Morales \(hemorale\)" , "Francois Audet" , "Jesske, R" , , Subject: Re: [Sip] Escaping rules of SIP-URI userpart Date: Tue, 3 Oct 2006 00:46:58 +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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > My question was whether it would be possible to use "#" unescapted in a > SIP-URI, since it would e.g speed up parsing, and mapping from TEL-URI > (where # IS allowed unescaped) to SIP-URI without having to first search > the the TEL-URI for a # character and escape it. The most recent relevant standard is RFC3986 which says in section 2.2 "URI producing applications should percent-encode data octets that correspond to characters in the reserved set unless these characters are specifically allowed by the URI scheme to represent data in that component.". And the "reserved set" includes "#" For tel: URIs RFC3966 explicitly allows '#' to represent data. RFC3261 does not do this for sip:, so it currently must be %-encoded Personally, I think the gain in parsing/mapping speed would be very small on a typical platform, at least not big enough to justify the effort of changing RFC3261. And parsers would end up supporting both for backwards compatibility reasons anyway. Regards, Jeroen PS apologies for the previous empty post. Believe it or not, my cat jumped on the keyboard _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 02 19:14:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWxU-0002rS-RH; Mon, 02 Oct 2006 19:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUWxT-0002rM-Op for sip@ietf.org; Mon, 02 Oct 2006 19:12:23 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUWxS-0004zj-II for sip@ietf.org; Mon, 02 Oct 2006 19:12:23 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20061002231221b1300lbfhne>; Mon, 2 Oct 2006 23:12:21 +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 k92NCLUm027128 for ; Mon, 2 Oct 2006 19:12:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k92NCLY3027124; Mon, 2 Oct 2006 19:12:21 -0400 Date: Mon, 2 Oct 2006 19:12:21 -0400 Message-Id: <200610022312.k92NCLY3027124@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <20061002113800.9794.qmail@web52807.mail.yahoo.com> (fenar@yahoo.com) Subject: Re: AW: [Sip] Escaping rules of SIP-URI userpart References: <20061002113800.9794.qmail@web52807.mail.yahoo.com> X-Spam-Score: 0.2 (/) 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: =?iso-8859-1?Q?Fatih_Ey=FCp_NAR?= you can check-out Q763 for SAM usage with IAM for the last paragraph Dale indicated however this partial dialed user mentality has no equivalency in sip afaik. There is a facility for allowing users to dial numbers partially, with the UA not knowing when the dial string ends, but it is not commonly used -- If the phone has collected some digits and sends them in a URI to the proxy, the proxy can respond "484 Address Incomplete" to indicate that more digits need to be provided. 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 Oct 02 20:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYOH-0007MV-Jl; Mon, 02 Oct 2006 20:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUYOG-0007Jv-1W for sip@ietf.org; Mon, 02 Oct 2006 20:44:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUYOF-0000RZ-GR for sip@ietf.org; Mon, 02 Oct 2006 20:44:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Oct 2006 17:44:07 -0700 X-IronPort-AV: i="4.09,246,1157353200"; d="scan'208"; a="44565402:sNHT76503316" 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 k930i7DU026326; Mon, 2 Oct 2006 20:44:07 -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 k930i6dM026530; Mon, 2 Oct 2006 20:44:06 -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, 2 Oct 2006 20:44:06 -0400 Received: from [10.86.242.13] ([10.86.242.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 20:44:06 -0400 Message-ID: <4521B253.2040406@cisco.com> Date: Mon, 02 Oct 2006 20:44:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A0007FD@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A0007FD@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2006 00:44:06.0358 (UTC) FILETIME=[07DCAF60:01C6E685] DKIM-Signature: a=rsa-sha1; q=dns; l=12040; t=1159836247; x=1160700247; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-sip-connecte=0A=20d-id=20entity-01=20comments) |To:=22Elwell,=20John=22=20; X=v=3Dcisco.com=3B=20h=3DC2jXf3+A2AvuO27+qMJKQ3q+DaU=3D; b=qo+aAQGH2pUqdHKfRb1LZPNnos1q3tK/+u81XcSybeO+g1i6I+JEnWwp7uFO1hAxONjBYgAe jds04OkjVGB57y/oVKxvUXmDj9T9emvbxs+ClcpsJt4+9XTxlOjo9VO5; 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: 8a4bcf8f67063cac573319207fe3db35 Cc: Cullen Jennings , SIP , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Thinking further on this, perhaps there is a 4th way: > > 4. Specify that if a UAS rejects a mid-dialog request with 436, 437 or 438, > then it MUST NOT invoke the verifier for a subsequent request This assumes that the verifier is invoked by the UAS, and not by some proxy in front of the UAS. Isn't it valid to have a verifier in a proxy before the UAS? This rule would forbid that, because it would cause that proxy to be call stateful. I think it would just be better to update the RFC, even though that is a bit more trouble than not to. Paul > on the same > dialog unless the From header field URI has changed, and in such cases > SHOULD NOT make use of the unverified connected-identity. Then a UAC, on > receiving 436, 437 or 438, MUST repeat the request once. This would allow > business as usual on this dialog (but without the benefit of connected > identity, therefore no worse than at present). It avoids any change to RFC > 4474, because verification is optional anyway. > > Would this work? > > John > >> -----Original Message----- >> From: Elwell, John >> Sent: 26 September 2006 21:02 >> To: Cullen Jennings; Jon Peterson >> Cc: SIP; Paul Kyzivat >> Subject: FW: Rejecting connected identity (was RE: >> draft-ietf-sip-connected-id entity-01 comments) >> >> Cullen, Jon, >> >> In case you missed this (it wasn't addressed directly to >> you), I would greatly appreciate an opinion from each of you >> on this remaining issue in connected-identity. Just to >> summarise, RFC 4474 leaves it up to policy whether to return >> a 428 response if Identity is missing, but mandates the >> sending of a 436, 437 or 438 response for certain errors >> arising while verifying the signature. It seems that for mid >> dialog requests this behaviour could be harmful. What does >> the UAC for the mid dialog request do if it receives 436, 437 >> or 438? If the mid-dialog request was solely for the purpose >> of connected identity, it can give up and allow the call to >> continue as is. But if the request was for some other purpose >> (e.g., renegotiating the session because of hold, say, or >> session timer refresh), the UAC really wants it to work. For >> the normal case where the Authentication Service is at a >> proxy, not at the UAC, the UAC cannot force the >> Authentication Service to refrain from putting this >> unverifiable signature in the mid-dialog request, so any >> attempts to repeat the request would most likely be doomed to >> getting the same response. >> >> It seems there are three things we could do, none very attractive: >> 1. Get connected-identity to modify the procedures of RFC >> 4474 for a verifier by softening the requirements for sending >> 436, 437 and 438 in response to mid-dialog requests. But then >> a mid-dialog request from a rogue source would be accepted. >> 2. Say that the Authentication Service should omit the >> signing of mid-dialog requests if a previous attempt has >> resulted in 436, 437 or 438. But this implies statefulness at the AS. >> 3. Accept the fact the mid-dialog requests can fail in this >> way and therefore things like session refresh and session >> renegotiation cannot be done, probably resulting in call >> failure. Sounds bad, but it is no different from an initial >> INVITE request, where there is nothing the UAC can do if the >> AS inserts an Identity header that gets rejected with 436, 437 or 438. >> >> John >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 22 September 2006 19:26 >>> To: Elwell, John >>> Cc: Cullen Jennings; SIP >>> Subject: Re: Rejecting connected identity (was RE: >>> draft-ietf-sip-connected-id entity-01 comments) >>> >>> John, >>> >>> I want to hear what others, especially Jon and Cullen, have >>> to say about >>> this. >>> >>> It is of some concern to me that a call might fail because of some >>> problem with the identity mechanism when the same call might have >>> succeeded in the absence of any identity. >>> >>> But possibly the solution to this is policy in the >>> implementation of the >>> verifier. What to do in the case of the conditions that >> lead to these >>> errors could be configurable in the verifier: either to >> generate the >>> error or simply to remove the identity info from the >> message. And the >>> policy could conceivably vary based on attributes of the >>> message, such >>> as whether it is in-dialog or not. >>> >>> Does it require a change to 4474 to permit that kind of policy? >>> >>> It would be annoying if the end user had no control over the >>> insertion >>> and verification of identity, and it resulted in calls >>> failing that the >>> user would like to permit. But I suppose that is itself a policy >>> decision. There are certainly enterprises that want to exert >>> that kind >>> of control over what users are permitted to do. >>> >>> Paul >>> >>> Elwell, John wrote: >>>> Paul, >>>> >>>> I agree with most of your points, and on reflection I think >>> I agree that the >>>> solution has to be with the verifier. >>>> >>>> I think RFC 4474 is not a problem as far as sending a 428 >>> 'Use Identity >>>> Header' response is concerned, because that is left to >>> policy, so we could >>>> say in connected-identity that policy should be to not send 428. >>>> >>>> However, 436, 437 and 438 responses are all a problem, >>> because RFC 4474 says >>>> that they MUST be sent under respective conditions. >>> Interestingly, though, >>>> there are other failure scenarios that can arise from the >>> procedures of >>>> section 6 of RFC 4474 for which no normative statement is >>> given on how to >>>> respond, e.g. invalid Date header field, signer not >>> authoritative for the >>>> domain. >>>> >>>> So one way to solve the present problem would be for the >>> connected-identity >>>> draft to modify verifier behaviour in RFC 4474 in the case >>> of mid-dialog >>>> requests. I guess this would mean that it would update RFC >>> 4474 as well as >>>> updating RFC 3261. But I don't like this, because it seems >>> to remove some of >>>> the security properties of RFC 4474. >>>> >>>> Another way would be to accept that 436, 437 and 438 >>> responses will be sent, >>>> and failure to verify a signature will therefore result in >>> inability to >>>> process the UPDATE or re-INVITE request, and hence if the >> UPDATE or >>>> re-INVITE request was for some other purpose such as >>> session timer refresh >>>> or modifying the session, that action will fail. Then the >>> call will fail (in >>>> the case of inability to refresh the session timer) or the session >>>> modification will fail. I guess this is somewhat analogous >>> to caller ID >>>> verification failure in an INVITE request - it is >>> impossible to establish a >>>> call if verification fails. Moreover, the UAC has no >>> ability to rectify the >>>> situation, since it is at the mercy of a proxy-based >>> Authentication Service >>>> that puts a rogue Identity header field in every request. >>> In the connected >>>> identity case, the only difference is that the call is >>> already established >>>> but is likely to fail if verification fails. >>>> >>>> Of course, if the mid-dialog request is indeed from the >>> wrong source, then >>>> sending a 436, 437 or 438 response is indeed the correct >>> thing to do, and >>>> overriding the verification procedures of RFC 4474 would >>> indeed be the wrong >>>> thing to do. So perhaps we just have to accept that these >>> response codes can >>>> be received and will lead to failure. >>>> >>>> So, my preferred way forward is simply to recommend not >>> sending a 428 and >>>> accept the consequences of other responses that the >>> verifier might send. >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 22 September 2006 15:13 >>>>> To: Elwell, John >>>>> Cc: Cullen Jennings; SIP >>>>> Subject: Re: [Sip] RE: >>> draft-ietf-sip-connected-identity-01 comments >>>>> >>>>> >>>>> Elwell, John wrote: >>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>> When an Update is sent. Are there any conditions under which >>>>>>> it might >>>>>>> be rejected. Bad identity for example. I think that >>> might need a >>>>>>> little discussion and also what the UA does when it sends >>>>> an update >>>>>>> with a no identity and it gets rejected. >>>>>> [JRE] A very good point. We don't want to get to a >>>>> situation where it is >>>>>> impossible to perform a mid-dialog request (e.g., for >>>>> purposes such as >>>>>> session timer refresh or session re-negotiation) just >>>>> because connected >>>>>> identity fails. >>>>>> My proposed fix is as follows: >>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>> with 428 'Use >>>>>> Identity Header'. >>>>> I'm not sure about this. At the least I think this one needs >>>>> some clear >>>>> explanation of the SHOULD NOT - about the conditions when >>> it can be >>>>> violated. >>>>> >>>>> I see this as somewhat analogous to doing a digest >> challenge on an >>>>> in-dialog request. In some cases it is the right thing to do. >>>>> >>>>> A UA that imposes such a requirement will be limited in what >>>>> it can do, >>>>> but that may still be right in some cases. >>>>> >>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>> Identity header field >>>>>> to a mid-dialog request if a previous request on that >>>>> dialog has resulted in >>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>> 438 'Invalid >>>>>> Identity Header'. >>>>> This requirement would force the authentication service to >>> be dialog >>>>> stateful, which is not ideal. Better to push the state >>> back into the >>>>> sender of the request. This may require a way for the UAC >>> to tell the >>>>> authentication service not to act. >>>>> >>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>> results in one of >>>>>> these responses if the mid-dialog request was not solely >>>>> for the purpose of >>>>>> connected identity. If solely for the purpose of connected >>>>> identity there is >>>>>> no point in repeating it, so I will say "SHOULD NOT take >>> any further >>>>>> action". >>>>> This seems wrong to me. >>>>> >>>>> I think that the remedy to these is in the verifier. The >>>>> purpose of the >>>>> verifier is ultimately to drive an authorization decision. If >>>>> authorization would succeed in the absence of the >>> identity, then the >>>>> request should be permitted to continue as if the identity >>>>> was not present. >>>>> >>>>> Unfortunately this would seem to require a revision to 4474 >>>>> even though >>>>> the paint is hardly dry on it. >>>>> >>>>> If this is done, then there is no need of a mechanism to >> cause the >>>>> authentication service *not* to authenticate. If this is >>> *not* done, >>>>> then that need remains, which will still require a >> change to 4474. >>>>> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 02 22:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUaMt-0005zG-OG; Mon, 02 Oct 2006 22:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUaMs-0005v9-QA for sip@ietf.org; Mon, 02 Oct 2006 22:50:50 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUaMq-0003ij-KK for sip@ietf.org; Mon, 02 Oct 2006 22:50:50 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <20061003025048012002ernoe>; Tue, 3 Oct 2006 02:50:48 +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 k932olUm000678 for ; Mon, 2 Oct 2006 22:50:47 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k932olRB000674; Mon, 2 Oct 2006 22:50:47 -0400 Date: Mon, 2 Oct 2006 22:50:47 -0400 Message-Id: <200610030250.k932olRB000674@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <17696.62145.560207.145984@rautu.tutpro.com> (jh@tutpro.com) Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart References: <451DA002.8060704@cisco.com> <5EB80D22825EEE42872083AD5BFFB59403CC27EB@esealmw113.eemea.ericsson.se> <17696.62145.560207.145984@rautu.tutpro.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: sip@ietf.org X-Mailman-Version: 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: Juha Heinanen perhaps the best solution is to get rid of URIs as sip addresses altogether and switch to JIDs. What's that? 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 Oct 02 23:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbIJ-0000jK-G1; Mon, 02 Oct 2006 23:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbIH-0000fJ-Q8 for sip@ietf.org; Mon, 02 Oct 2006 23:50:09 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUbID-0000lI-Uy for sip@ietf.org; Mon, 02 Oct 2006 23:50:09 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by hoemail2.lucent.com (8.13.6/IER-o) with ESMTP id k933nvDf019365 for ; Mon, 2 Oct 2006 22:49:58 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Oct 2006 11:49:24 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Oct 2006 11:49:24 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] Early media query Date: Tue, 3 Oct 2006 11:49:23 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Early media query thread-index: AcbmIJab3ngqkgz2T2SAYnlU+d5jbwAAUFSQAB63CIA= From: "Xia, Zhi Feng \(Bruce\)" To: "Christer Holmberg \(JO/LMF\)" , , X-OriginalArrivalTime: 03 Oct 2006 03:49:24.0063 (UTC) FILETIME=[EA87D6F0:01C6E69E] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea0c5ffa0d480ecee26cc89bc870d672 Cc: sip-implementors@cs.columbia.edu X-BeenThere: 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="===============1682369247==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1682369247== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E69E.EA272B50" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E69E.EA272B50 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I prefer method 4. This is also the requirement of some big service = provider's application(e.g. China Telecom CRBT application). Note the = media attibute in 183 should be set to "sendonly". =20 Regards, Zhifeng -----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] Sent: 2006=C4=EA10=D4=C22=C8=D5 20:57 To: Udit_Goyal@3com.com; sip@ietf.org Cc: sip-implementors@cs.columbia.edu Subject: RE: [Sip] Early media query =20 Hi, =20 You can use Method 2, assuming the 18x and 200 have different To tag = values. Otherwise you can use Method 3 or 4 (message 9 in Method 3, and = message 7 in Method 4, seem to go in the wrong direction, though). =20 Regards, =20 Christer =20 =20 =20 =20 =20 _____ =20 From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]=20 Sent: 2. lokakuuta 2006 12:57 To: sip@ietf.org Cc: sip-implementors@cs.columbia.edu Subject: [Sip] Early media query Hi,=20 I want to made an application where we can use early media for playing = initial in-band announcements, and then finally connecting the caller to = actual callee (eg prepaid card application).=20 I want to know which is the correct way to support this as per SIP RFC.=20 Method 1:=20 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) 200 OK with SDP |=20 |<----------------------------|=20 | |=20 | |=20 |(4) ACK |=20 |---------------------------->|=20 | |=20 (2) contains SDP of announcement server=20 (3) contains SDP of callee=20 Method 2:=20 Caller = Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 | |=20 | |=20 |(5) 200 INVITE with sdp |=20 |<----------------------------|=20 | |=20 | |=20 |(6) ACK |=20 |---------------------------->|=20 | |=20 | |=20 | |=20 | |=20 (2) contains SDP of announcement server=20 (5) contains SDP of callee=20 Method 3:=20 Caller Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 |(5) 200 OK |=20 |<----------------------------|=20 | |=20 |(6) ACK |=20 |---------------------------->|=20 | |=20 |(7)Re-INVITE with SDP |=20 |<----------------------------|=20 | |=20 | |=20 |(8) 200 OK with SDP |=20 |---------------------------->|=20 | |=20 |(9) ACK |=20 |---------------------------->|=20 (2) contains SDP of announcement server=20 (5) contains no SDP=20 (7) contains SDP of callee=20 (8) contains answer of caller for callee offer=20 Her, UDATE can also be used instead of Re-invites.=20 Method 4:=20 Caller = Callee=20 | |=20 | |=20 |(1) INVITE with offer |=20 |---------------------------->|=20 | |=20 | |=20 |(2) 183 with answer 1 |=20 |<----------------------------|=20 | |=20 | |=20 |(3) PRACK |=20 |---------------------------->|=20 | |=20 | |=20 |(4) 200 PRACK |=20 |<----------------------------|=20 |(5) UPDATE (callee offer) |=20 |<----------------------------|=20 | |=20 |(6) 200 UPDATE (answer) |=20 |---------------------------->|=20 | |=20 |(7) 200 INVITE |=20 |---------------------------->|=20 | |=20 |(8) ACK |=20 |---------------------------->|=20 In this case, when callee answers, UPDATE is sent to caller to negoitate = audio with caller, and then 200 OK is sent for the initial INVITE.=20 Regards,=20 Udit ------_=_NextPart_001_01C6E69E.EA272B50 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I = prefer method=20 4. This is also the requirement of some big service provider's = application(e.g.=20 China Telecom CRBT application). Note the media attibute in 183 should = be set to=20 "sendonly".
 
Regards,
Zhifeng
-----Original Message-----
From: Christer Holmberg = (JO/LMF)=20 [mailto:christer.holmberg@ericsson.com]
Sent: = 2006=C4=EA10=D4=C22=C8=D5=20 20:57
To: Udit_Goyal@3com.com; sip@ietf.org
Cc:=20 sip-implementors@cs.columbia.edu
Subject: RE: [Sip] Early = media=20 query

 
Hi,
 
You=20 can use Method 2, assuming the 18x and 200 have different To tag = values.=20 Otherwise you can use Method 3 or 4 (message 9 in Method 3, and = message 7 in=20 Method 4, seem to go in the wrong direction, = though).
 
Regards,
 
Christer
 
 
 
 
 

From: Udit_Goyal@3com.com=20 [mailto:Udit_Goyal@3com.com]
Sent: 2. lokakuuta 2006=20 12:57
To: sip@ietf.org
Cc:=20 sip-implementors@cs.columbia.edu
Subject: [Sip] Early = media=20 query


Hi, =

I want to made an application where we = can use early=20 media for playing initial in-band announcements, and then finally = connecting=20 the caller to actual callee (eg prepaid card application).=20

I want to know which is the = correct way=20 to support this as per SIP RFC.

Method 1:


 =20                Caller   =  =20                  =20  Callee
  =    =20              |     =  =20                   =    =20 |
    =    =20            |       =  =20                   =  =20 |
    =    =20            |(1) INVITE with offer =  =20      |
 =20                =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(2) 183 with answer 1        | =
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |             =  =20               |
          =    =20      |(3) 200 OK with SDP         =  |
    =  =20            =20  |<----------------------------|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(4) ACK               =  =20      |
 =20                =20  |---------------------------->|
                =  =20  |                 =  =20           |


(2) contains SDP of announcement = server=20
(3) contains SDP of = callee=20


Method 2: =

            =  =20                   =    =20     Caller =    =20                  =20  Callee
  =    =20              |     =  =20                   =    =20 |
    =    =20            |       =  =20                   =  =20 |
    =    =20            |(1) INVITE with offer =  =20      |
 =20                =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(2) 183 with answer 1        | =
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |             =  =20               |
          =    =20      |(3) PRACK           =  =20        |
                =  =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(4) 200 PRACK             =  =20  |
    =  =20            =20  |<----------------------------|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20                 =  |=20
        =  =20          |(5) 200 INVITE with sdp   =  =20  |
    =  =20            =20  |<----------------------------|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(6) ACK               =  =20      |
 =20                =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |

(2) contains SDP of announcement server
(5) contains SDP of callee =


Method 3:

        Caller               =    =20      Callee
 =20                  | =  =20                   =    =20     |
   =20                |   =  =20                   =    =20   |
  =    =20              |(1) INVITE with = offer=20        |
                =  =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(2) 183 with answer 1        | =
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |             =  =20               |
          =    =20      |(3) PRACK           =  =20        |
                =  =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(4) 200 PRACK             =  =20  |
    =  =20            =20  |<----------------------------|
                =  =20  |(5) 200 OK               =  =20   |
  =    =20            =20  |<----------------------------|
                =  =20  |                 =  =20           |
                =  =20  |(6) ACK               =  =20      |
 =20                =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |(7)Re-INVITE with SDP        | =
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |             =  =20               |
          =    =20      |(8) 200 OK with SDP         =  |
    =  =20            =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |(9) ACK               =  =20      |
 =20                =20  |---------------------------->|

(2) contains SDP of announcement = server=20
(5) contains no SDP =
(7) contains SDP of callee =
(8) contains answer of caller for callee = offer=20

Her, UDATE can also be used = instead of=20 Re-invites.

Method = 4:=20

        =  =20                   =    =20             Caller               =    =20      Callee
 =20                  | =  =20                   =    =20     |
   =20                |   =  =20                   =    =20   |
  =    =20              |(1) INVITE with = offer=20        |
                =  =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(2) 183 with answer 1        | =
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |             =  =20               |
          =    =20      |(3) PRACK           =  =20        |
                =  =20  |---------------------------->|
                =  =20  |                 =  =20           |
                =  =20  |                 =  =20           |
                =  =20  |(4) 200 PRACK             =  =20  |
    =  =20            =20  |<----------------------------|
                =  =20  |(5) UPDATE (callee offer)    |
          =    =20      |<----------------------------| =
          =    =20      |             =  =20               |
          =    =20      |(6) 200 UPDATE (answer)     =  |=20
        =  =20          |---------------------------->| =
      =  =20            |       =  =20                   =  =20 |
    =    =20            |(7) 200=20 = INVITE           &= nbsp;   |=20
        =  =20         =  |---------------------------->|=20
        =  =20          |         =  =20                   = |=20
        =  =20          |(8) ACK       =  =20              |
          =    =20      |---------------------------->|=20


In this case, = when callee=20 answers, UPDATE is sent to caller to negoitate audio with caller, = and then=20 200 OK is sent for the initial INVITE.

Regards,
Udit
------_=_NextPart_001_01C6E69E.EA272B50-- --===============1682369247== 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 --===============1682369247==-- From sip-bounces@ietf.org Mon Oct 02 23:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbOo-0005T2-GX; Mon, 02 Oct 2006 23:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbOn-0005Su-FU for sip@ietf.org; Mon, 02 Oct 2006 23:56:53 -0400 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUbOl-0002Yh-SC for sip@ietf.org; Mon, 02 Oct 2006 23:56:53 -0400 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Oct 2006 20:56:30 -0700 From: "Darshan Bildikar" To: "'Retesh Chadha'" , Date: Tue, 3 Oct 2006 09:26:27 +0530 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: AcbmIgVe3zH9Q/4ASqSIJlqTMxTcNAAfa9+Q In-Reply-To: Message-ID: X-OriginalArrivalTime: 03 Oct 2006 03:56:31.0152 (UTC) FILETIME=[E9187300:01C6E69F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Early media query X-BeenThere: sip@ietf.org X-Mailman-Version: 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 that even Method 3 and 4 are OK because they will involve a change in the origin line parameter of the SDP and that is not allowed as per the RFC. BTW, what was the rationale behind not allowing the origin line to change? It makes implementing apps like prepaid and CRBT very difficult. Could someone please throw some light on this? -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha Sent: Monday, October 02, 2006 5:46 PM To: Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Early media query Hi Udit Of all the methods you have specified, Method 1 and 2 are wrong as per the RFC which states that the sdp of all the provisional and 2xx response of INVITE should be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in that case 200 ok for INVITE is only sent when the final negotiation (call media) is done. Hope this helps. -- With Regards Retesh Chadha On 10/2/06, Udit_Goyal@3com.com wrote: > Hi, > > I want to made an application where we can use early media for playing > initial in-band announcements, and then finally connecting the caller to > actual callee (eg prepaid card application). > > I want to know which is the correct way to support this as per SIP RFC. > > Method 1: > > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) 200 OK with SDP | > |<----------------------------| > | | > | | > |(4) ACK | > |---------------------------->| > | | > > > (2) contains SDP of announcement server > (3) contains SDP of callee > > > Method 2: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > | | > | | > |(5) 200 INVITE with sdp | > |<----------------------------| > | | > | | > |(6) ACK | > |---------------------------->| > | | > | | > | | > | | > > (2) contains SDP of announcement server > (5) contains SDP of callee > > > Method 3: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) 200 OK | > |<----------------------------| > | | > |(6) ACK | > |---------------------------->| > | | > |(7)Re-INVITE with SDP | > |<----------------------------| > | | > | | > |(8) 200 OK with SDP | > |---------------------------->| > | | > |(9) ACK | > |---------------------------->| > > (2) contains SDP of announcement server > (5) contains no SDP > (7) contains SDP of callee > (8) contains answer of caller for callee offer > > Her, UDATE can also be used instead of Re-invites. > > Method 4: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) UPDATE (callee offer) | > |<----------------------------| > | | > |(6) 200 UPDATE (answer) | > |---------------------------->| > | | > |(7) 200 INVITE | > |---------------------------->| > | | > |(8) ACK | > |---------------------------->| > > > In this case, when callee answers, UPDATE is sent to caller to negoitate > audio with caller, and then 200 OK is sent for the initial INVITE. > > Regards, > Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 00:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUcEv-00056d-TC; Tue, 03 Oct 2006 00:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUcEu-00056Y-Ch for sip@ietf.org; Tue, 03 Oct 2006 00:50:44 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUcEq-0002xy-1T for sip@ietf.org; Tue, 03 Oct 2006 00:50:44 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B9F1413F60A; Tue, 3 Oct 2006 07:50:31 +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 (guanine23.gprs.dnafinland.fi [62.78.120.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D525113F605; Tue, 3 Oct 2006 07:50:21 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 4C46BF0258; Tue, 3 Oct 2006 07:51:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17697.60469.135419.587710@rautu.tutpro.com> Date: Tue, 3 Oct 2006 07:51:01 +0300 From: Juha Heinanen To: Dale.Worley@comcast.net Subject: Re: VS: [Sip] Escaping rules of SIP-URI userpart In-Reply-To: <200610030250.k932olRB000674@dragon.ariadne.com> References: <451DA002.8060704@cisco.com> <5EB80D22825EEE42872083AD5BFFB59403CC27EB@esealmw113.eemea.ericsson.se> <17696.62145.560207.145984@rautu.tutpro.com> <200610030250.k932olRB000674@dragon.ariadne.com> X-Mailer: VM 7.19 under Emacs 21.4.1 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 Dale.Worley@comcast.net writes: > perhaps the best solution is to get rid of URIs as sip addresses > altogether and switch to JIDs. > > What's that? see http://www.xmpp.org/specs/rfc3920.html#addressing also this document claims RFC 2396 [URI] compatibility, but still allow #. -- 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 Tue Oct 03 01:46:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUd4B-00081h-5F; Tue, 03 Oct 2006 01:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUd48-000808-K3 for sip@ietf.org; Tue, 03 Oct 2006 01:43:40 -0400 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUcpJ-0005hH-Ko for sip@ietf.org; Tue, 03 Oct 2006 01:28:22 -0400 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Oct 2006 22:28:17 -0700 From: "Darshan Bildikar" To: "'Manpreet Singh'" , "'Retesh Chadha'" , Subject: RE: [Sip] RE: [Sip-implementors] Early media query Date: Tue, 3 Oct 2006 10:58:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbmpU6jBT/aFAV5R2Cy/vUDh03NCQAB1/Ow In-Reply-To: <6E9C6C7D27E3714190801A551BE376100391E6C6@server507.bur.ibasis.net> Message-ID: X-OriginalArrivalTime: 03 Oct 2006 05:28:18.0074 (UTC) FILETIME=[BB7A0FA0:01C6E6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Quoting RFC 3264 Section 8 =A0=A0 Nearly all aspects of the session can be modified.=A0 New streams = can =A0=A0 be added, existing streams can be deleted, and parameters of = existing =A0=A0 streams can change.=A0 When issuing an offer that modifies the = session, =A0=A0 the "o=3D" line of the new SDP MUST be identical to that in the =A0=A0 previous SDP, except that the version in the origin field MUST =A0=A0 increment by one from the previous SDP Why I am saying there is a problem with this is because In the first answer you are probably giving the caller the announcement server SDP (i.e. something like o=3Dmediaserver) and then later updating = it with the callee SDP (i.e. something like o=3Dcalleeside). If you don=92t = have a B2BUA in between that actually changes the origin line of SDP (i.e. to something like o=3DAPPSERVER) then the flows would actually be invalid = because of this restriction.=20 The flows that are described are generally used. I am not saying that = they must not be used. What I am saying is that the RFC 3264 places a = restriction on them in terms of origin line.=20 However, I don=92t think this restriction is valid, coz if a change the = IP is allowed why not a change in origin line?=20 This is what I am trying to get clarified.=20 ________________________________________ From: Manpreet Singh [mailto:msingh@ibasis.net]=20 Sent: Tuesday, October 03, 2006 9:56 AM To: Darshan Bildikar; 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: [Sip-implementors] Early media query Importance: High I would say 3 makes total sense as the Re-invite is happening after a = dialog is complete so not sure why the spec wont allow it. So it would be more = or less a mid call change ( in confirmed state ) happening from a callee = side which would be the application server trying to bridge the call to the called party skipping the announcement server. 3 should work fine and = the origin field has to be changed because now the call needs to be bridged = to the called party which is a whole new endpoint supporting different = codecs with different connection identifiers etc. I'd say why not just send the 200OK with the answer to the initial offer = in the Invite and then play the annoucement and then bridge using a = re-invite. Unless you are trying to save the time charged till the annoucement is played, which a lot of prepaid apps try to do, then this thing gets complicated. I guess in that case, the application server can send the answer in rel-183 and then the moment the call needs to be bridged, send = a 200Ok and a re-invite, which is exactly what is shown in (3).=20 M=20 -----Original Message-----=20 From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 Sent: Monday, October 02, 2006 11:56 PM=20 To: 'Retesh Chadha'; Udit_Goyal@3com.com=20 Cc: sip@ietf.org; sip-implementors@cs.columbia.edu=20 Subject: [Sip] RE: [Sip-implementors] Early media query=20 I don't think that even Method 3 and 4 are OK because they will involve = a change in the origin line parameter of the SDP and that is not allowed = as per the RFC.=20 BTW, what was the rationale behind not allowing the origin line to = change?=20 It makes implementing apps like prepaid and CRBT very difficult. Could someone please throw some light on this?=20 -----Original Message-----=20 From: sip-implementors-bounces@cs.columbia.edu=20 [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh = Chadha Sent: Monday, October 02, 2006 5:46 PM=20 To: Udit_Goyal@3com.com=20 Cc: sip@ietf.org; sip-implementors@cs.columbia.edu=20 Subject: Re: [Sip-implementors] Early media query=20 Hi Udit=20 Of all the methods you have specified, Method 1 and 2 are wrong as per = the RFC which states that the sdp of all the provisional and 2xx response of INVITE should be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in = that case 200 ok for INVITE is only sent when the final negotiation (call = media) is done. Hope this helps.=20 --=20 With Regards=20 Retesh Chadha=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 Oct 03 03:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeJn-0006co-5B; Tue, 03 Oct 2006 03:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUeJm-0006cj-6c for sip@ietf.org; Tue, 03 Oct 2006 03:03:54 -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 1GUeJj-00037k-D5 for sip@ietf.org; Tue, 03 Oct 2006 03:03:54 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6J00K01SYNE6@siemenscomms.co.uk> for sip@ietf.org; Tue, 03 Oct 2006 08:03:59 +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 <0J6J00I5XSYNRJ@siemenscomms.co.uk>; Tue, 03 Oct 2006 08:03:59 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SRTSW>; Tue, 03 Oct 2006 08:03:45 +0100 Content-return: allowed Date: Tue, 03 Oct 2006 08:03:44 +0100 From: "Elwell, John" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) To: Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A00083E@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: 46ad68ada464411807db2a0edd5648ae Cc: Cullen Jennings , SIP , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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, So your proposal is that the connected-identity RFC should update RFC 4474 to somehow relax rules at a verifier. Correct? So the next question concerns the way in which these rules should be relaxed. One problem with the verifier not being located at the UAS but at some proxy is that the UAS might be configured always to trust identities received in requests via the verifier's proxy if an Identity header field is present, on the assumption that the signature has been checked by the verifier. Therefore it sounds like the verifier, if it does not reject a request with a bad signature, should remove the Identity header field (and also Identity-Info) before forwarding the request towards the target. Under what conditions should a verifier remove an Identity header field rather than rejecting with 436/437/438? My inclination would be to leave it as a matter of policy as far as the update to RFC 4474 is concerned, and then make more precise statements concerning mid-dialog requests. Alternatively the update to RFC 4474 could just relax the rules for mid-dialog requests. I think there is some merit in relaxing the rules in general, because otherwise there might be situations where a legitimate caller cannot establish a call because an Authentication Service (outside the UAC's control) is inserting an unverifiable signature (e.g., in Identity-Info placing a URL that the Verifier cannot dereference for some reason). One consequence of the Verifier being separated from the UAS is that we don't want to rely on stateful behaviour at the Verifier or its proxy (for similar reasons that you cited for the Authentication Service earlier). So for mid-dialog requests we would need to mandate, or at least recommend, that 436/437/438 should not be sent. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 03 October 2006 01:44 > To: Elwell, John > Cc: Cullen Jennings; Jon Peterson; SIP > Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > draft-ietf-sip-connecte d-id entity-01 comments) > > > > Elwell, John wrote: > > Thinking further on this, perhaps there is a 4th way: > > > > 4. Specify that if a UAS rejects a mid-dialog request with > 436, 437 or 438, > > then it MUST NOT invoke the verifier for a subsequent request > > This assumes that the verifier is invoked by the UAS, and not by some > proxy in front of the UAS. Isn't it valid to have a verifier > in a proxy > before the UAS? This rule would forbid that, because it would > cause that > proxy to be call stateful. > > I think it would just be better to update the RFC, even > though that is a > bit more trouble than not to. > > Paul > > > on the same > > dialog unless the From header field URI has changed, and in > such cases > > SHOULD NOT make use of the unverified connected-identity. > Then a UAC, on > > receiving 436, 437 or 438, MUST repeat the request once. > This would allow > > business as usual on this dialog (but without the benefit > of connected > > identity, therefore no worse than at present). It avoids > any change to RFC > > 4474, because verification is optional anyway. > > > > Would this work? > > > > John > > > >> -----Original Message----- > >> From: Elwell, John > >> Sent: 26 September 2006 21:02 > >> To: Cullen Jennings; Jon Peterson > >> Cc: SIP; Paul Kyzivat > >> Subject: FW: Rejecting connected identity (was RE: > >> draft-ietf-sip-connected-id entity-01 comments) > >> > >> Cullen, Jon, > >> > >> In case you missed this (it wasn't addressed directly to > >> you), I would greatly appreciate an opinion from each of you > >> on this remaining issue in connected-identity. Just to > >> summarise, RFC 4474 leaves it up to policy whether to return > >> a 428 response if Identity is missing, but mandates the > >> sending of a 436, 437 or 438 response for certain errors > >> arising while verifying the signature. It seems that for mid > >> dialog requests this behaviour could be harmful. What does > >> the UAC for the mid dialog request do if it receives 436, 437 > >> or 438? If the mid-dialog request was solely for the purpose > >> of connected identity, it can give up and allow the call to > >> continue as is. But if the request was for some other purpose > >> (e.g., renegotiating the session because of hold, say, or > >> session timer refresh), the UAC really wants it to work. For > >> the normal case where the Authentication Service is at a > >> proxy, not at the UAC, the UAC cannot force the > >> Authentication Service to refrain from putting this > >> unverifiable signature in the mid-dialog request, so any > >> attempts to repeat the request would most likely be doomed to > >> getting the same response. > >> > >> It seems there are three things we could do, none very attractive: > >> 1. Get connected-identity to modify the procedures of RFC > >> 4474 for a verifier by softening the requirements for sending > >> 436, 437 and 438 in response to mid-dialog requests. But then > >> a mid-dialog request from a rogue source would be accepted. > >> 2. Say that the Authentication Service should omit the > >> signing of mid-dialog requests if a previous attempt has > >> resulted in 436, 437 or 438. But this implies statefulness > at the AS. > >> 3. Accept the fact the mid-dialog requests can fail in this > >> way and therefore things like session refresh and session > >> renegotiation cannot be done, probably resulting in call > >> failure. Sounds bad, but it is no different from an initial > >> INVITE request, where there is nothing the UAC can do if the > >> AS inserts an Identity header that gets rejected with 436, > 437 or 438. > >> > >> John > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 22 September 2006 19:26 > >>> To: Elwell, John > >>> Cc: Cullen Jennings; SIP > >>> Subject: Re: Rejecting connected identity (was RE: > >>> draft-ietf-sip-connected-id entity-01 comments) > >>> > >>> John, > >>> > >>> I want to hear what others, especially Jon and Cullen, have > >>> to say about > >>> this. > >>> > >>> It is of some concern to me that a call might fail > because of some > >>> problem with the identity mechanism when the same call might have > >>> succeeded in the absence of any identity. > >>> > >>> But possibly the solution to this is policy in the > >>> implementation of the > >>> verifier. What to do in the case of the conditions that > >> lead to these > >>> errors could be configurable in the verifier: either to > >> generate the > >>> error or simply to remove the identity info from the > >> message. And the > >>> policy could conceivably vary based on attributes of the > >>> message, such > >>> as whether it is in-dialog or not. > >>> > >>> Does it require a change to 4474 to permit that kind of policy? > >>> > >>> It would be annoying if the end user had no control over the > >>> insertion > >>> and verification of identity, and it resulted in calls > >>> failing that the > >>> user would like to permit. But I suppose that is itself a policy > >>> decision. There are certainly enterprises that want to exert > >>> that kind > >>> of control over what users are permitted to do. > >>> > >>> Paul > >>> > >>> Elwell, John wrote: > >>>> Paul, > >>>> > >>>> I agree with most of your points, and on reflection I think > >>> I agree that the > >>>> solution has to be with the verifier. > >>>> > >>>> I think RFC 4474 is not a problem as far as sending a 428 > >>> 'Use Identity > >>>> Header' response is concerned, because that is left to > >>> policy, so we could > >>>> say in connected-identity that policy should be to not send 428. > >>>> > >>>> However, 436, 437 and 438 responses are all a problem, > >>> because RFC 4474 says > >>>> that they MUST be sent under respective conditions. > >>> Interestingly, though, > >>>> there are other failure scenarios that can arise from the > >>> procedures of > >>>> section 6 of RFC 4474 for which no normative statement is > >>> given on how to > >>>> respond, e.g. invalid Date header field, signer not > >>> authoritative for the > >>>> domain. > >>>> > >>>> So one way to solve the present problem would be for the > >>> connected-identity > >>>> draft to modify verifier behaviour in RFC 4474 in the case > >>> of mid-dialog > >>>> requests. I guess this would mean that it would update RFC > >>> 4474 as well as > >>>> updating RFC 3261. But I don't like this, because it seems > >>> to remove some of > >>>> the security properties of RFC 4474. > >>>> > >>>> Another way would be to accept that 436, 437 and 438 > >>> responses will be sent, > >>>> and failure to verify a signature will therefore result in > >>> inability to > >>>> process the UPDATE or re-INVITE request, and hence if the > >> UPDATE or > >>>> re-INVITE request was for some other purpose such as > >>> session timer refresh > >>>> or modifying the session, that action will fail. Then the > >>> call will fail (in > >>>> the case of inability to refresh the session timer) or > the session > >>>> modification will fail. I guess this is somewhat analogous > >>> to caller ID > >>>> verification failure in an INVITE request - it is > >>> impossible to establish a > >>>> call if verification fails. Moreover, the UAC has no > >>> ability to rectify the > >>>> situation, since it is at the mercy of a proxy-based > >>> Authentication Service > >>>> that puts a rogue Identity header field in every request. > >>> In the connected > >>>> identity case, the only difference is that the call is > >>> already established > >>>> but is likely to fail if verification fails. > >>>> > >>>> Of course, if the mid-dialog request is indeed from the > >>> wrong source, then > >>>> sending a 436, 437 or 438 response is indeed the correct > >>> thing to do, and > >>>> overriding the verification procedures of RFC 4474 would > >>> indeed be the wrong > >>>> thing to do. So perhaps we just have to accept that these > >>> response codes can > >>>> be received and will lead to failure. > >>>> > >>>> So, my preferred way forward is simply to recommend not > >>> sending a 428 and > >>>> accept the consequences of other responses that the > >>> verifier might send. > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: 22 September 2006 15:13 > >>>>> To: Elwell, John > >>>>> Cc: Cullen Jennings; SIP > >>>>> Subject: Re: [Sip] RE: > >>> draft-ietf-sip-connected-identity-01 comments > >>>>> > >>>>> > >>>>> Elwell, John wrote: > >>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>> When an Update is sent. Are there any conditions under which > >>>>>>> it might > >>>>>>> be rejected. Bad identity for example. I think that > >>> might need a > >>>>>>> little discussion and also what the UA does when it sends > >>>>> an update > >>>>>>> with a no identity and it gets rejected. > >>>>>> [JRE] A very good point. We don't want to get to a > >>>>> situation where it is > >>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>> purposes such as > >>>>>> session timer refresh or session re-negotiation) just > >>>>> because connected > >>>>>> identity fails. > >>>>>> My proposed fix is as follows: > >>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>>> with 428 'Use > >>>>>> Identity Header'. > >>>>> I'm not sure about this. At the least I think this one needs > >>>>> some clear > >>>>> explanation of the SHOULD NOT - about the conditions when > >>> it can be > >>>>> violated. > >>>>> > >>>>> I see this as somewhat analogous to doing a digest > >> challenge on an > >>>>> in-dialog request. In some cases it is the right thing to do. > >>>>> > >>>>> A UA that imposes such a requirement will be limited in what > >>>>> it can do, > >>>>> but that may still be right in some cases. > >>>>> > >>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>> Identity header field > >>>>>> to a mid-dialog request if a previous request on that > >>>>> dialog has resulted in > >>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or > >>>>> 438 'Invalid > >>>>>> Identity Header'. > >>>>> This requirement would force the authentication service to > >>> be dialog > >>>>> stateful, which is not ideal. Better to push the state > >>> back into the > >>>>> sender of the request. This may require a way for the UAC > >>> to tell the > >>>>> authentication service not to act. > >>>>> > >>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>> results in one of > >>>>>> these responses if the mid-dialog request was not solely > >>>>> for the purpose of > >>>>>> connected identity. If solely for the purpose of connected > >>>>> identity there is > >>>>>> no point in repeating it, so I will say "SHOULD NOT take > >>> any further > >>>>>> action". > >>>>> This seems wrong to me. > >>>>> > >>>>> I think that the remedy to these is in the verifier. The > >>>>> purpose of the > >>>>> verifier is ultimately to drive an authorization decision. If > >>>>> authorization would succeed in the absence of the > >>> identity, then the > >>>>> request should be permitted to continue as if the identity > >>>>> was not present. > >>>>> > >>>>> Unfortunately this would seem to require a revision to 4474 > >>>>> even though > >>>>> the paint is hardly dry on it. > >>>>> > >>>>> If this is done, then there is no need of a mechanism to > >> cause the > >>>>> authentication service *not* to authenticate. If this is > >>> *not* done, > >>>>> then that need remains, which will still require a > >> change to 4474. > >>>>> 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 > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 03:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUf59-0007wH-In; Tue, 03 Oct 2006 03:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUf58-0007so-1s for sip@ietf.org; Tue, 03 Oct 2006 03:52:50 -0400 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUf52-0001Ap-Kj for sip@ietf.org; Tue, 03 Oct 2006 03:52:50 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k937qfWU016462; Tue, 3 Oct 2006 09:52:41 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k937qeAK020015; Tue, 3 Oct 2006 09:52:40 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 09:52:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-01 Date: Tue, 3 Oct 2006 09:52:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: Comments on draft-niemi-sip-subnot-etags-01 thread-index: AcbmFcJliXcl7g7RRCyOdGrKC3fkDwAn4zmQ From: "Vrancken, Johnny" To: "Aki Niemi" X-OriginalArrivalTime: 03 Oct 2006 07:52:36.0902 (UTC) FILETIME=[E48A5C60:01C6E6C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Aki, Thanks for clarifying the distinction between "no body" and "null body" in a SIP message, something I wasn't aware of.=20 I have no strong opinion on whether "no body" or "null body" is to be notified in case Suppress-Body-If-Match applies. I just want to comment on your statement: > I would think that the RLS aggregates resource state it receives via the > backend subscriptions. For instance, even if there are n buddies > watching M, the RLS only makes a single backend subscription to M. This might be true on particular conditions, but surely is not generally the case. One of the preconditions is that the RLS has access to and can apply M's authorization rules (subscription authorizations and privacy filters). Please note that I support promoting your document as a WG item, as it is a rather simple means to reduce the message size and number of messages between UAC and UAS. Kind regards, Johnny _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 08:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUj0t-0004Oo-Hx; Tue, 03 Oct 2006 08:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUj0s-0004Oj-Af for sip@ietf.org; Tue, 03 Oct 2006 08:04:42 -0400 Received: from server100.appriver.com ([207.97.227.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUj0r-00086W-QF for sip@ietf.org; Tue, 03 Oct 2006 08:04:42 -0400 Received: by server100.appriver.com (CommuniGate Pro PIPE 5.0.9) with PIPE id 80724781; Tue, 03 Oct 2006 08:04:44 -0400 Received: from [216.168.161.154] (HELO BUR-SR7-QDL580-1.ivanet.net) by server100.appriver.com (CommuniGate Pro SMTP 5.0.9) with SMTP id 80724771; Tue, 03 Oct 2006 08:04:35 -0400 Received: from server507.ibasis.net ([216.168.160.47]) by BUR-SR7-QDL580-1.ivanet.net (SMSSMTP 4.0.0.59) with SMTP id M2006100307485024128 ; Tue, 03 Oct 2006 07:48:50 -0400 Received: by server507.bur.ibasis.net with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Oct 2006 07:59:31 -0400 Message-ID: <6E9C6C7D27E3714190801A551BE376100391E76F@server507.bur.ibasis.net> From: Manpreet Singh To: Darshan Bildikar , 'Retesh Chadha' , Udit_Goyal@3com.com Subject: RE: [Sip] RE: [Sip-implementors] Early media query Date: Tue, 3 Oct 2006 07:59:30 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: msingh@ibasis.net ALLOWED X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->UNITED STATES->destination X-Note-Sending-IP: 216.168.161.154 X-Note-Reverse-DNS: BUR-SR7-QDL580-1.ivanet.net X-Note-WHTLIST: msingh@ibasis.net X-Note: User Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Spam-Score: 0.6 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: 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="===============0187895810==" Errors-To: sip-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0187895810== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E6E3.620EF570" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6E6E3.620EF570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes agreed but arent we assuming that the application server doing the prepaid application is really a B2BUA so the origin field is always the B2BUA but the stream is changed based on where the media is played from = or bridged to? Also my bad with the origin field, got mixed with the = version field. M -----Original Message----- From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 Sent: Tuesday, October 03, 2006 1:28 AM To: 'Manpreet Singh'; 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: [Sip-implementors] Early media query Quoting RFC 3264 Section 8 =A0=A0 Nearly all aspects of the session can be modified.=A0 New = streams can =A0=A0 be added, existing streams can be deleted, and parameters of = existing =A0=A0 streams can change.=A0 When issuing an offer that modifies the = session, =A0=A0 the "o=3D" line of the new SDP MUST be identical to that in the =A0=A0 previous SDP, except that the version in the origin field MUST =A0=A0 increment by one from the previous SDP Why I am saying there is a problem with this is because In the first answer you are probably giving the caller the announcement server SDP (i.e. something like o=3Dmediaserver) and then later = updating it with the callee SDP (i.e. something like o=3Dcalleeside). If you don't = have a B2BUA in between that actually changes the origin line of SDP (i.e. to something like o=3DAPPSERVER) then the flows would actually be invalid = because of this restriction.=20 The flows that are described are generally used. I am not saying that = they must not be used. What I am saying is that the RFC 3264 places a = restriction on them in terms of origin line.=20 However, I don't think this restriction is valid, coz if a change the = IP is allowed why not a change in origin line?=20 This is what I am trying to get clarified.=20 ________________________________________ From: Manpreet Singh [mailto:msingh@ibasis.net] Sent: Tuesday, October 03, 2006 9:56 AM To: Darshan Bildikar; 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: [Sip-implementors] Early media query Importance: High I would say 3 makes total sense as the Re-invite is happening after a = dialog is complete so not sure why the spec wont allow it. So it would be more = or less a mid call change ( in confirmed state ) happening from a callee = side which would be the application server trying to bridge the call to the called party skipping the announcement server. 3 should work fine and = the origin field has to be changed because now the call needs to be bridged = to the called party which is a whole new endpoint supporting different = codecs with different connection identifiers etc. I'd say why not just send the 200OK with the answer to the initial = offer in the Invite and then play the annoucement and then bridge using a = re-invite. Unless you are trying to save the time charged till the annoucement is played, which a lot of prepaid apps try to do, then this thing gets complicated. I guess in that case, the application server can send the answer in rel-183 and then the moment the call needs to be bridged, = send a 200Ok and a re-invite, which is exactly what is shown in (3).=20 M -----Original Message----- From: Darshan Bildikar [mailto:dbildikar@ipunity.com] Sent: Monday, October 02, 2006 11:56 PM To: 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Early media query I don't think = that even Method 3 and 4 are OK because they will involve a change in the = origin line parameter of the SDP and that is not allowed as per the RFC.=20 BTW, what was the rationale behind not allowing the origin line to = change?=20 It makes implementing apps like prepaid and CRBT very difficult. Could someone please throw some light on this?=20 -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh = Chadha Sent: Monday, October 02, 2006 5:46 PM To: Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Early media query Hi Udit Of all the = methods you have specified, Method 1 and 2 are wrong as per the RFC which = states that the sdp of all the provisional and 2xx response of INVITE should = be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in = that case 200 ok for INVITE is only sent when the final negotiation (call = media) is done. Hope this helps.=20 -- With Regards Retesh Chadha=20 ------_=_NextPart_001_01C6E6E3.620EF570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: [Sip-implementors] Early media query

Yes agreed but arent we assuming that the application = server doing the prepaid application is really a B2BUA so the origin = field is always the B2BUA but the stream is changed based on where the = media is played from or bridged to? Also my bad with the origin field, = got mixed with the version field.

M

-----Original Message-----
From: Darshan Bildikar [mailto:dbildikar@ipunity.com] =
Sent: Tuesday, October 03, 2006 1:28 AM
To: 'Manpreet Singh'; 'Retesh Chadha'; = Udit_Goyal@3com.com
Cc: sip@ietf.org; = sip-implementors@cs.columbia.edu
Subject: RE: [Sip] RE: [Sip-implementors] Early = media query

Quoting RFC 3264 Section 8


=A0=A0 Nearly all aspects of the session can be = modified.=A0 New streams can
=A0=A0 be added, existing streams can be deleted, = and parameters of existing
=A0=A0 streams can change.=A0 When issuing an offer = that modifies the session,
=A0=A0 the "o=3D" line of the new SDP MUST = be identical to that in the
=A0=A0 previous SDP, except that the version in the = origin field MUST
=A0=A0 increment by one from the previous SDP

Why I am saying there is a problem with this is = because

In the first answer you are probably giving the = caller the announcement server SDP (i.e. something like = o=3Dmediaserver) and then later updating it with the callee SDP (i.e. = something like o=3Dcalleeside). If you don't have a B2BUA in between = that actually changes the origin line of SDP (i.e. to something like = o=3DAPPSERVER) then the flows would actually be invalid because of this = restriction.

The flows that are described are generally used. I am = not saying that they must not be used. What I am saying is that the RFC = 3264 places a restriction on them in terms of origin line.

However, I don't think this restriction is valid, coz = if a change the IP is allowed why not a change in origin line?

This is what I am trying to get clarified.


________________________________________
From: Manpreet Singh [mailto:msingh@ibasis.net]
Sent: Tuesday, October 03, 2006 9:56 AM
To: Darshan Bildikar; 'Retesh Chadha'; = Udit_Goyal@3com.com
Cc: sip@ietf.org; = sip-implementors@cs.columbia.edu
Subject: RE: [Sip] RE: [Sip-implementors] Early = media query
Importance: High

I would say 3 makes total sense as the Re-invite is = happening after a dialog is complete so not sure why the spec wont = allow it. So it would be more or less a mid call change ( in confirmed = state ) happening from a callee side which would be the application = server trying to bridge the call to the called party skipping the = announcement server. 3 should work fine and the origin field has to be = changed because now the call needs to be bridged to the called party = which is a whole new endpoint supporting different codecs with = different connection identifiers etc.

I'd say why not just send the 200OK with the answer = to the initial offer in the Invite and then play the annoucement and = then bridge using a re-invite.

Unless you are trying to save the time charged till = the annoucement is played, which a lot of prepaid apps try to do, then = this thing gets complicated. I guess in that case, the application = server can send the answer in rel-183 and then the moment the call = needs to be bridged, send a 200Ok and a re-invite, which is exactly = what is shown in (3).

M
-----Original Message-----
From: Darshan Bildikar [mailto:dbildikar@ipunity.com]<= /FONT>
Sent: Monday, October 02, 2006 11:56 PM
To: 'Retesh Chadha'; Udit_Goyal@3com.com
Cc: sip@ietf.org; = sip-implementors@cs.columbia.edu
Subject: [Sip] RE: [Sip-implementors] Early media = query I don't think that even Method 3 and 4 are OK because they will = involve a change in the origin line parameter of the SDP and that is = not allowed as per the RFC.

BTW, what was the rationale behind not allowing the = origin line to change?
It makes implementing apps like prepaid and CRBT = very difficult. Could someone please throw some light on this?
-----Original Message-----
From: = sip-implementors-bounces@cs.columbia.edu
[mailto:sip-impl= ementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha

Sent: Monday, October 02, 2006 5:46 PM
To: Udit_Goyal@3com.com
Cc: sip@ietf.org; = sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Early media query Hi = Udit Of all the methods you have specified, Method 1 and 2 are wrong as = per the RFC which states that the sdp of all the provisional and 2xx = response of INVITE should be same if they are present.

Both Method 3 and 4 look fine, with method 4 being = better because in that case 200 ok for INVITE is only sent when the = final negotiation (call media) is done.

Hope this helps.
--
With Regards
Retesh Chadha

------_=_NextPart_001_01C6E6E3.620EF570-- --===============0187895810== 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 --===============0187895810==-- From sip-bounces@ietf.org Tue Oct 03 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnwJ-0000DR-PT; Tue, 03 Oct 2006 13:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUMnA-000614-Fa for sip@ietf.org; Mon, 02 Oct 2006 08:21:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUMi2-0004LK-DO for sip@ietf.org; Mon, 02 Oct 2006 08:15:48 -0400 Received: by nf-out-0910.google.com with SMTP id n15so1595590nfc for ; Mon, 02 Oct 2006 05:15:45 -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=QH0aaimVkr8eRYzGsOM7JC46BQsiB8ZUDAH3iKOA0ICoplAGmT/ASTrOiuPi5Hn5dxDWbw/eUwvQtot+i7DEaAiSMOFFQJQh0RNKAi+TJ+wX3LbqJ8fKGYLwWnXAVMRwCeQi4mUv2ywH1MmL1EqufYynkPV37L8T76HZ0VA7pKQ= Received: by 10.49.41.18 with SMTP id t18mr5572793nfj; Mon, 02 Oct 2006 05:15:45 -0700 (PDT) Received: by 10.49.81.12 with HTTP; Mon, 2 Oct 2006 05:15:45 -0700 (PDT) Message-ID: Date: Mon, 2 Oct 2006 17:45:45 +0530 From: "Retesh Chadha" To: "Udit_Goyal@3com.com" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 X-Mailman-Approved-At: Tue, 03 Oct 2006 13:20:17 -0400 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Early media query X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Udit Of all the methods you have specified, Method 1 and 2 are wrong as per the RFC which states that the sdp of all the provisional and 2xx response of INVITE should be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in that case 200 ok for INVITE is only sent when the final negotiation (call media) is done. Hope this helps. -- With Regards Retesh Chadha On 10/2/06, Udit_Goyal@3com.com wrote: > Hi, > > I want to made an application where we can use early media for playing > initial in-band announcements, and then finally connecting the caller to > actual callee (eg prepaid card application). > > I want to know which is the correct way to support this as per SIP RFC. > > Method 1: > > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) 200 OK with SDP | > |<----------------------------| > | | > | | > |(4) ACK | > |---------------------------->| > | | > > > (2) contains SDP of announcement server > (3) contains SDP of callee > > > Method 2: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > | | > | | > |(5) 200 INVITE with sdp | > |<----------------------------| > | | > | | > |(6) ACK | > |---------------------------->| > | | > | | > | | > | | > > (2) contains SDP of announcement server > (5) contains SDP of callee > > > Method 3: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) 200 OK | > |<----------------------------| > | | > |(6) ACK | > |---------------------------->| > | | > |(7)Re-INVITE with SDP | > |<----------------------------| > | | > | | > |(8) 200 OK with SDP | > |---------------------------->| > | | > |(9) ACK | > |---------------------------->| > > (2) contains SDP of announcement server > (5) contains no SDP > (7) contains SDP of callee > (8) contains answer of caller for callee offer > > Her, UDATE can also be used instead of Re-invites. > > Method 4: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) UPDATE (callee offer) | > |<----------------------------| > | | > |(6) 200 UPDATE (answer) | > |---------------------------->| > | | > |(7) 200 INVITE | > |---------------------------->| > | | > |(8) ACK | > |---------------------------->| > > > In this case, when callee answers, UPDATE is sent to caller to negoitate > audio with caller, and then 200 OK is sent for the initial INVITE. > > Regards, > Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnvH-00088r-6u; Tue, 03 Oct 2006 13:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUcmH-0004tP-DR for sip@ietf.org; Tue, 03 Oct 2006 01:25:13 -0400 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUcmE-0005Zj-UO for sip@ietf.org; Tue, 03 Oct 2006 01:25:13 -0400 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Oct 2006 22:24:48 -0700 From: "Darshan Bildikar" To: "'Manpreet Singh'" , "'Retesh Chadha'" , Subject: RE: [Sip] RE: [Sip-implementors] Early media query Date: Tue, 3 Oct 2006 10:54:47 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcbmpU6jBT/aFAV5R2Cy/vUDh03NCQABouEw In-Reply-To: <6E9C6C7D27E3714190801A551BE376100391E6C6@server507.bur.ibasis.net> Message-ID: X-OriginalArrivalTime: 03 Oct 2006 05:24:49.0184 (UTC) FILETIME=[3EF7FA00:01C6E6AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 99f473fda9635c21a2e5fa5cc4ac13ac X-Mailman-Approved-At: Tue, 03 Oct 2006 13:19:14 -0400 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: 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="===============1814685456==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1814685456== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C6E6DA.59EE8260" This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C6E6DA.59EE8260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Quoting RFC 3264 Section 8 Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP Why I am saying there is a problem with this is because In the first answer you are probably giving the caller the announcement server SDP (i.e. something like o=mediaserver) and then later updating it with the callee SDP (i.e. something like o=calleeside). If you don't have a B2BUA in between that actually changes the origin line of SDP (i.e. to something like o=APPSERVER) then the flows would actually be invalid because of this restriction. The flows that are described are generally used. I am not saying that they must not be used. What I am saying is that the RFC 3264 places a restriction on them in terms of origin line. However, I don't think this restriction is valid, coz if a change the IP is allowed why not a change in origin line? This is what I am trying to get clarified. _____ From: Manpreet Singh [mailto:msingh@ibasis.net] Sent: Tuesday, October 03, 2006 9:56 AM To: Darshan Bildikar; 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: RE: [Sip] RE: [Sip-implementors] Early media query Importance: High I would say 3 makes total sense as the Re-invite is happening after a dialog is complete so not sure why the spec wont allow it. So it would be more or less a mid call change ( in confirmed state ) happening from a callee side which would be the application server trying to bridge the call to the called party skipping the announcement server. 3 should work fine and the origin field has to be changed because now the call needs to be bridged to the called party which is a whole new endpoint supporting different codecs with different connection identifiers etc. I'd say why not just send the 200OK with the answer to the initial offer in the Invite and then play the annoucement and then bridge using a re-invite. Unless you are trying to save the time charged till the annoucement is played, which a lot of prepaid apps try to do, then this thing gets complicated. I guess in that case, the application server can send the answer in rel-183 and then the moment the call needs to be bridged, send a 200Ok and a re-invite, which is exactly what is shown in (3). M -----Original Message----- From: Darshan Bildikar [mailto:dbildikar@ipunity.com] Sent: Monday, October 02, 2006 11:56 PM To: 'Retesh Chadha'; Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Early media query I don't think that even Method 3 and 4 are OK because they will involve a change in the origin line parameter of the SDP and that is not allowed as per the RFC. BTW, what was the rationale behind not allowing the origin line to change? It makes implementing apps like prepaid and CRBT very difficult. Could someone please throw some light on this? -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha Sent: Monday, October 02, 2006 5:46 PM To: Udit_Goyal@3com.com Cc: sip@ietf.org; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Early media query Hi Udit Of all the methods you have specified, Method 1 and 2 are wrong as per the RFC which states that the sdp of all the provisional and 2xx response of INVITE should be same if they are present. Both Method 3 and 4 look fine, with method 4 being better because in that case 200 ok for INVITE is only sent when the final negotiation (call media) is done. Hope this helps. -- With Regards Retesh Chadha On 10/2/06, Udit_Goyal@3com.com wrote: > Hi, > > I want to made an application where we can use early media for playing > initial in-band announcements, and then finally connecting the caller to > actual callee (eg prepaid card application). > > I want to know which is the correct way to support this as per SIP RFC. > > Method 1: > > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) 200 OK with SDP | > |<----------------------------| > | | > | | > |(4) ACK | > |---------------------------->| > | | > > > (2) contains SDP of announcement server > (3) contains SDP of callee > > > Method 2: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > | | > | | > |(5) 200 INVITE with sdp | > |<----------------------------| > | | > | | > |(6) ACK | > |---------------------------->| > | | > | | > | | > | | > > (2) contains SDP of announcement server > (5) contains SDP of callee > > > Method 3: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) 200 OK | > |<----------------------------| > | | > |(6) ACK | > |---------------------------->| > | | > |(7)Re-INVITE with SDP | > |<----------------------------| > | | > | | > |(8) 200 OK with SDP | > |---------------------------->| > | | > |(9) ACK | > |---------------------------->| > > (2) contains SDP of announcement server > (5) contains no SDP > (7) contains SDP of callee > (8) contains answer of caller for callee offer > > Her, UDATE can also be used instead of Re-invites. > > Method 4: > > Caller Callee > | | > | | > |(1) INVITE with offer | > |---------------------------->| > | | > | | > |(2) 183 with answer 1 | > |<----------------------------| > | | > | | > |(3) PRACK | > |---------------------------->| > | | > | | > |(4) 200 PRACK | > |<----------------------------| > |(5) UPDATE (callee offer) | > |<----------------------------| > | | > |(6) 200 UPDATE (answer) | > |---------------------------->| > | | > |(7) 200 INVITE | > |---------------------------->| > | | > |(8) ACK | > |---------------------------->| > > > In this case, when callee answers, UPDATE is sent to caller to negoitate > audio with caller, and then 200 OK is sent for the initial INVITE. > > Regards, > Udit > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------=_NextPart_000_005B_01C6E6DA.59EE8260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: [Sip-implementors] Early media query

Quoting RFC 3264 Section = 8

 

 

   Nearly all aspects of the session can be = modified.  New streams can

   be added, existing streams can be deleted, and = parameters of existing

   streams can change.  When issuing an offer = that modifies the session,

   the "o=3D" line of the new SDP MUST be = identical to that in the

   previous SDP, except that the version in the origin = field MUST

   increment by one from the previous = SDP

 

Why I am saying there is a problem = with this is because

 

In the = first answer you are probably giving the caller the announcement server SDP = (i.e. something like o=3Dmediaserver) and then later updating it with the = callee SDP (i.e. something like o=3Dcalleeside). If you don’t have a B2BUA in = between that actually changes the origin line of SDP (i.e. to something like o=3DAPPSERVER) then the flows would actually be invalid because of this restriction.

 

The = flows that are described are generally used. I am not saying that they must not be = used. What I am saying is that the RFC 3264 places a restriction on them in = terms of origin line.

 

However, I = don’t think this restriction is valid, coz if a change the IP is allowed why not a = change in origin line?

 

This is what I am = trying to get clarified.

 

From: Manpreet Singh [mailto:msingh@ibasis.net]
Sent: Tuesday, October = 03, 2006 9:56 AM
To: Darshan Bildikar; = 'Retesh Chadha'; Udit_Goyal@3com.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: RE: [Sip] RE: [Sip-implementors] Early media query
Importance: = High

 

I would say 3 makes total sense as the Re-invite is happening after a dialog is complete so not sure why the spec wont allow it. So it would be more or = less a mid call change ( in confirmed state ) happening from a callee side = which would be the application server trying to bridge the call to the called party skipping the announcement server. 3 should work fine and the origin = field has to be changed because now the call needs to be bridged to the called = party which is a whole new endpoint supporting different codecs with different connection identifiers etc.

I'd say why not just send the 200OK with the answer to the initial offer in the = Invite and then play the annoucement and then bridge using a re-invite. Unless = you are trying to save the time charged till the annoucement is played, which a = lot of prepaid apps try to do, then this thing gets complicated. I guess in = that case, the application server can send the answer in rel-183 and then the = moment the call needs to be bridged, send a 200Ok and a re-invite, which is exactly = what is shown in (3).

M

-----Original Message-----
From: Darshan Bildikar = [mailto:dbildikar@ipunity.com] =
Sent: Monday, October = 02, 2006 11:56 PM
To: 'Retesh Chadha'; Udit_Goyal@3com.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: [Sip] RE: [Sip-implementors] Early media query

I don't think that even Method 3 and 4 are OK because they will involve a change = in the origin line parameter of the SDP and that is not allowed as per the RFC. =

BTW, what was the rationale behind not allowing the origin line to = change?
It makes implementing = apps like prepaid and CRBT very difficult. Could someone please throw some light = on this?

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-imple= mentors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha
Sent: Monday, October = 02, 2006 5:46 PM
To: = Udit_Goyal@3com.com
Cc: sip@ietf.org; sip-implementors@cs.columbia.edu
Subject: Re: = [Sip-implementors] Early media query

Hi Udit
Of all the methods you = have specified, Method 1 and 2 are wrong as per the RFC which states that the = sdp of all the provisional and 2xx response of INVITE should be same if they = are present.

Both Method 3 and 4 look fine, with method 4 being better because in that = case 200 ok for INVITE is only sent when the final negotiation (call media) is = done.

Hope this helps.
--
With = Regards
Retesh = Chadha

 

On 10/2/06, Udit_Goyal@3com.com <Udit_Goyal@3com.com> = wrote:
> Hi, =
>
> I want to made an = application where we can use early media for playing
> initial in-band = announcements, and then finally connecting the caller to
> actual callee (eg = prepaid card application).
>
> I want to know = which is the correct way to support this as per SIP RFC.
>
> Method = 1:
>
>
>       =           Caller           &= nbsp;            Callee
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(1) INVITE with offer        = |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(2) 183 with answer 1        = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(3) 200 OK with = SDP          = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(4) ACK           &nbs= p;          |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>
>
> (2) contains SDP of announcement server
> (3) contains SDP of = callee
>
>
> Method = 2:
>
>       =             &= nbsp;           &n= bsp;        Caller Callee
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(1) INVITE with offer        = |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(2) 183 with answer 1        = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(3) PRACK           &n= bsp;        |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(4) 200 PRACK           &n= bsp;    |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(5) 200 INVITE with sdp      | =
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(6) ACK           &nbs= p;          |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>
> (2) contains SDP of announcement server
> (5) contains SDP of = callee
>
>
> Method = 3:
>
>       = Caller           &= nbsp;            Callee
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(1) INVITE with offer        = |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(2) 183 with answer 1        = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(3) PRACK           &n= bsp;        |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(4) 200 PRACK           &n= bsp;    |
>       =             |<----------------------------|
>       =             |(5) 200 OK            = ;       |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |(6) ACK           &nbs= p;          |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |(7)Re-INVITE with SDP        = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(8) 200 OK with = SDP          = |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |(9) ACK           &nbs= p;          |
>       =             |---------------------------->|
>
> (2) contains SDP of announcement server
> (5) contains no = SDP
> (7) contains SDP of = callee
> (8) contains answer = of caller for callee offer
>
> Her, UDATE can also = be used instead of Re-invites.
>
> Method = 4:
>
>       =             &= nbsp;           &n= bsp;            Caller Callee
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(1) INVITE with offer        = |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(2) 183 with answer 1        = |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(3) = PRACK           &n= bsp;        |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |            =             &= nbsp;    |
>       =             |(4) 200 PRACK           &n= bsp;    |
>       =             |<----------------------------|
>       =             |(5) UPDATE (callee offer)    |
>       =             |<----------------------------|
>       =             |            =             &= nbsp;    |
>       =             |(6) 200 UPDATE (answer)      | =
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |(7) 200 INVITE           &= nbsp;       |
>       =             |---------------------------->|
>       =             |            =             &= nbsp;    |
>       =             |(8) ACK           &nbs= p;          |
>       =             |---------------------------->|
>
>
> In this case, when = callee answers, UPDATE is sent to caller to negoitate
> audio with caller, = and then 200 OK is sent for the initial INVITE.
>
> = Regards,
> Udit =
> _______________________________________________
> Sip-implementors = mailing list
> Sip-implementors@cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-im= plementors
>
______________________________________________= _
Sip-implementors mailing = list
Sip-implementors@cs.columbia.edu=
https://lists.cs.columbia.edu/cucslists/listinfo/sip-im= plementors

 

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

------=_NextPart_000_005B_01C6E6DA.59EE8260-- --===============1814685456== 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 --===============1814685456==-- From sip-bounces@ietf.org Tue Oct 03 13:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUnv3-0007o7-8X; Tue, 03 Oct 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 1GSwVC-00080M-SE for sip@ietf.org; Thu, 28 Sep 2006 10:04:38 -0400 Received: from nz-out-0102.google.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSwVA-0002zk-Ao for sip@ietf.org; Thu, 28 Sep 2006 10:04:38 -0400 Received: by nz-out-0102.google.com with SMTP id q3so255488nzb for ; Thu, 28 Sep 2006 07:04:36 -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:references; b=eHiC5Od/iiE9uXvWW5jp2wYYFnf8yNnlEfGlVlsDcSi+9EV1QDbaksCvuJAqygB/mpkNZMe/y6Tj/l11EtJsooLZO9ef5GWOXlezMp0Wz+CREvHrncKaBn+jIDjioYUVIAkW/V3myYcIh5KrpHhTD3pVelEKjOww5n3Ny8g4bV8= Received: by 10.65.119.14 with SMTP id w14mr1920516qbm; Thu, 28 Sep 2006 07:04:35 -0700 (PDT) Received: by 10.65.237.6 with HTTP; Thu, 28 Sep 2006 07:04:35 -0700 (PDT) Message-ID: <6f5185a0609280704h34ad1f0y3cbc6d45998d6c85@mail.gmail.com> Date: Thu, 28 Sep 2006 20:04:35 +0600 From: "Apoorva Bais" To: "Udit_Goyal@3com.com" In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.6 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Tue, 03 Oct 2006 13:18:59 -0400 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] PRACK query X-BeenThere: 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="===============1239970688==" Errors-To: sip-bounces@ietf.org --===============1239970688== Content-Type: multipart/alternative; boundary="----=_Part_22191_13155451.1159452275794" ------=_Part_22191_13155451.1159452275794 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Udit ! First 2 paragraph seem to be correct ! Not sure about the UPDATE thing ,I believe UPDATE would change the Original request ! So in a way UPDATE would not have the same intention as 183 and PRACK ! Correct me if i am wrong ! Regards, asb On 9/28/06, Udit_Goyal@3com.com wrote: > > Hi, > > Please let me know if my understanding is correct for regular session > offer-answer when PRACK is used: > > For INVITE containing SDP, and if offer answer done in the using reliable > 183 response for early media, 200 OK response SDP will have an answer for > the regular session, so 200 OK SDP will be answer to the offer sent in > initial SDP. > > Similarly, if INVITE does not have SDP, and if offer-answer done using > PRACK, still 200 OK will contain the regular session offer and answer will > be present n the ACK message. > > Similarly, if UPDATE is used for offer-answer before call is connected, it > will not affect the regular session offer-answer, it will be taken care by > initial INVITE , final 200 OK and ACK message. > > Thank,s > Udit > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > ------=_Part_22191_13155451.1159452275794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Udit !
 
First 2 paragraph seem to be correct !
Not sure about the UPDATE thing ,I believe UPDATE would change the Original request !
So in a way UPDATE would not have the same intention as 183 and PRACK !
Correct me if i am wrong !
 
Regards,
 
asb

 
On 9/28/06, Udit_Goyal@3com.com <Udit_Goyal@3com.com> wrote:
Hi,

Please let me know if my understanding is correct for regular session
offer-answer when PRACK is used:

For INVITE containing SDP, and if offer answer done in the using reliable
183 response for early media, 200 OK response SDP will have an answer for
the regular session, so 200 OK SDP will be answer to the offer sent in
initial SDP.

Similarly, if INVITE does not  have SDP, and if offer-answer done using
PRACK, still 200 OK will contain the regular session offer and answer will
be present n the ACK message.

Similarly, if UPDATE is used for offer-answer before call is connected, it
will not affect the regular session offer-answer, it will be taken care by
initial INVITE , final 200 OK and ACK message.

Thank,s
Udit

_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

------=_Part_22191_13155451.1159452275794-- --===============1239970688== 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 --===============1239970688==-- From sip-bounces@ietf.org Tue Oct 03 14:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUosq-000852-CV; Tue, 03 Oct 2006 14:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUosp-00084s-NM for sip@ietf.org; Tue, 03 Oct 2006 14:20:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUosm-0006zv-C5 for sip@ietf.org; Tue, 03 Oct 2006 14:20:47 -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 k93HNYFU012935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Oct 2006 12:23:35 -0500 Message-ID: <4522AA1F.4040604@softarmor.com> Date: Tue, 03 Oct 2006 13:21:19 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> In-Reply-To: <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: SIP , Pete Cordell , Robert Sparks X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > > I don't think we should require any specific hash but I think it would > be nice to give implementors some advice on what might be a reasonable > choice. So does this mean we need a change to the draft, or did we decide to stand with the current text? -- 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 Oct 03 14:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUp8a-00075r-Rm; Tue, 03 Oct 2006 14:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUp8Y-00074S-QL for sip@ietf.org; Tue, 03 Oct 2006 14:37:02 -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 1GUp8X-0002KD-FJ for sip@ietf.org; Tue, 03 Oct 2006 14:37:02 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.4) with ESMTP id k93Iavlu007363 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 3 Oct 2006 13:36:58 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <4522AA1F.4040604@softarmor.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 13:36:57 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Cullen Jennings , SIP , Pete Cordell X-BeenThere: sip@ietf.org X-Mailman-Version: 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 are other changes to the draft that I've agreed to make, so there will be a new version (shortly). This question isn't pinned down yet though. The draft _doesn't_ require any specific hash. It gives advice on a reasonable choice. It goes further to characterize properties of other choices an implementation might make, where it trips over this bit-count that gave people different kinds of heatburn. I propose just pulling the bit-length description and instead point to the lack-of-collision property that folks need to take into account. We are already careful not to say "cryptographic", but I'll probably add a comment making the lack-of-cryptographic-requirement more explicit. RjS On Oct 3, 2006, at 1:21 PM, Dean Willis wrote: > Cullen Jennings wrote: >> I don't think we should require any specific hash but I think it >> would be nice to give implementors some advice on what might be a >> reasonable choice. > > So does this mean we need a change to the draft, or did we decide > to stand with the current text? > > -- > 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 Oct 03 14:42:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpBv-0005iE-M9; Tue, 03 Oct 2006 14:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpBu-0005i9-Uo for sip@ietf.org; Tue, 03 Oct 2006 14:40:30 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpBt-0003FS-LQ for sip@ietf.org; Tue, 03 Oct 2006 14:40: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 k93HhXuV013033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Oct 2006 12:43:34 -0500 Message-ID: <4522AECE.3060005@softarmor.com> Date: Tue, 03 Oct 2006 13:41:18 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "sip@ietf.org" Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> In-Reply-To: <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org jbemmel@zonnet.nl wrote: > Major technical comment on section 5.8: the proposed Trigger-Consent > mechanism looks like one big hack to me. It does not comply with > RFC3515, and appears to be an inappropriate use of REFER. Suggestion: > use SUBSCRIBE / NOTIFY > > Technical comment on Trigger-Consent: the ABNF in section 5.11 allows > multiple instances of this header. Is this desired? If so, a note on > what should be done when multiple instances are present is needed. If > not, the ABNF should be adapted ( I suspect the latter is the > appropriate choice ) > > Minor technical comment on Figure 5 and the example in 5.11: the > escaping of the Refer-To URI is invalid, '<' and '>' should be %-encoded > too (but: see first comment, suggest to remove this Refer-To header > entirely) Ok, good comments. Anybody else read this draft? I'm worried that we're not really getting the needed level of review here. Suggestions? -- 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 Oct 03 14:47:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpGp-00016m-Qs; Tue, 03 Oct 2006 14:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpGo-00016h-EC for sip@ietf.org; Tue, 03 Oct 2006 14:45:34 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpGn-0004PC-5U for sip@ietf.org; Tue, 03 Oct 2006 14:45:34 -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 k93IjQ0e000237; Tue, 3 Oct 2006 13:45:28 -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 k93IjPk13211; Tue, 3 Oct 2006 13:45:25 -0500 (CDT) Message-ID: <4522AFC5.10306@lucent.com> Date: Tue, 03 Oct 2006 13:45:25 -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: 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: d6b246023072368de71562c0ab503126 Cc: Subject: [Sip] I-D on handling large UDP responses X-BeenThere: sip@ietf.org X-Mailman-Version: 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: An I-D on handling large UDP response has just been submitted to the I-D editor. Until it appears in the archives, a copy can be obtained from: http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html The draft suggests the use of 1xx-class responses to solve this problem. Please look at the draft and provide comments and/or concerns. 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 Tue Oct 03 15:03:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpVc-00025f-7P; Tue, 03 Oct 2006 15:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpVa-00025a-JC for sip@ietf.org; Tue, 03 Oct 2006 15:00:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpVW-00061D-99 for sip@ietf.org; Tue, 03 Oct 2006 15:00:50 -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 k93I3mgZ013148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Oct 2006 13:03:51 -0500 Message-ID: <4522B38D.3090407@softarmor.com> Date: Tue, 03 Oct 2006 14:01:33 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> In-Reply-To: <4522AFC5.10306@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: > Folks: An I-D on handling large UDP response has just been > submitted to the I-D editor. Until it appears in the archives, a > copy can be obtained from: > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html > > > The draft suggests the use of 1xx-class responses to solve this > problem. > > Please look at the draft and provide comments and/or concerns. > > Thank you. > > - vijay So, are we stuck on advancing the hop-limit-diagnostics draft until we advance something like this draft? -- 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 Oct 03 15:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpcM-0000Bx-2o; Tue, 03 Oct 2006 15:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpcL-0000Br-8T for sip@ietf.org; Tue, 03 Oct 2006 15:07:49 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpcI-0006xX-Ty for sip@ietf.org; Tue, 03 Oct 2006 15:07:49 -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 k93IATca013185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Oct 2006 13:10:30 -0500 Message-ID: <4522B51F.1040102@softarmor.com> Date: Tue, 03 Oct 2006 14:08:15 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] sec-flows-01 submitted References: <2909C853-8604-4A69-A21A-A9D8D6098BC1@nostrum.com> In-Reply-To: <2909C853-8604-4A69-A21A-A9D8D6098BC1@nostrum.com> 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 , Cullen Jennings , "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 Robert Sparks wrote: > An update to the security flows document has been submitted. > Until it appears in the repository, you can find it at > http://www.nostrum.com/~rjsparks/draft-ietf-sip-sec-flows-01.txt > > Here's a copy of the change log: > > -00 to -01 > * Incorporated the Test cases from Vijay Gurbani's and Alan > Jeffrey's Use of TLS in SIP draft > * Began to capture the folklore around where identities are > carried in certificates for use with SIP > * Removed the message dump archive pending verification (will > return in -02) > > > In particular, please read and comment on the section capturing current > folklore. > > I am well on the way to automating the creation of the message > signatures and dumps > in this draft, but there are a few wrinkles to iron out still, so I have > not made the changes > to, for example, the Accept header fields in the example messages yet. > I haven't seen anything on the list since this went out. I'm hoping the author got lots of lovely feedback that somehow didn't make it onto the list. Any comment on that, Robert? -- 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 Oct 03 15:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpgD-00022U-1h; Tue, 03 Oct 2006 15:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpgB-00022P-KZ for sip@ietf.org; Tue, 03 Oct 2006 15:11:47 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpgA-0007Wx-Bx for sip@ietf.org; Tue, 03 Oct 2006 15:11:47 -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 k93JBjKP015643; Tue, 3 Oct 2006 14:11:45 -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 k93JBjk05808; Tue, 3 Oct 2006 14:11:45 -0500 (CDT) Message-ID: <4522B5F1.8010602@lucent.com> Date: Tue, 03 Oct 2006 14:11:45 -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: Dean Willis Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <4522B38D.3090407@softarmor.com> In-Reply-To: <4522B38D.3090407@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: > So, are we stuck on advancing the hop-limit-diagnostics draft until we > advance something like this draft? Umm ... at least I see these as two distinct pieces of work...no? - 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 Oct 03 15:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpiF-0003NH-4C; Tue, 03 Oct 2006 15:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUpiD-0003NB-SN for sip@ietf.org; Tue, 03 Oct 2006 15:13:53 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUpiA-0007ra-IF for sip@ietf.org; Tue, 03 Oct 2006 15:13:53 -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 k93JDmLv021313; Tue, 3 Oct 2006 14:13:48 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 14:13:48 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 21:13:46 +0200 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 Date: Tue, 3 Oct 2006 21:13:45 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918051599A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progress of draft-ietf-sip-location-conveyance Thread-Index: AcbnIAxgIh2aV9aGRAaA9nUR44Wciw== From: "Drage, Keith \(Keith\)" To: , "Brian Rosen" X-OriginalArrivalTime: 03 Oct 2006 19:13:46.0332 (UTC) FILETIME=[0C9E79C0:01C6E720] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org Subject: [Sip] Progress of draft-ietf-sip-location-conveyance X-BeenThere: sip@ietf.org X-Mailman-Version: 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 the -04 version of this issued back in August, where we had a fairly substantial rewrite by the authors. Does the rewrite improve the document?? There have in the view of the WG chairs been sufficient comments made to justify a new version before the IETF cutoff, and therefore we ask the authors to produce that new version. We have been concerned at the absence of list discussion so we would encourage SIP experts to review this draft, so that some more work can be included in an updated version. 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 Tue Oct 03 15:38:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq2Y-0002hV-NF; Tue, 03 Oct 2006 15:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUq2W-0002hP-RW for sip@ietf.org; Tue, 03 Oct 2006 15:34:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUq2V-0003ml-I9 for sip@ietf.org; Tue, 03 Oct 2006 15:34:52 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 12:34:51 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208"; a="327743469:sNHT54674904" 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 k93JYpLK022533; Tue, 3 Oct 2006 12:34:51 -0700 Received: from [192.168.1.3] (sjc-vpn6-396.cisco.com [10.21.121.140]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k93JYkML020121; Tue, 3 Oct 2006 12:34:46 -0700 (PDT) In-Reply-To: <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 12:34:45 -0700 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1826; t=1159904091; x=1160768091; 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]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DAyadtlHzVE2lqPGk6mddYA9NTlg=3D; b=IGwAaCInUyA0odMBdQjTNfhRW4ouqxW4O+HU8UaYVTwuyQkHQ6xMymgpIMMvng0P/rEhs3zp fvHJ1bVmjyOqLR6Gg9BzxGYUN/WQu+Ih/Ovi25JTvm/RmAEsmt8dQkka; 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIP , Pete Cordell , 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 So my vague recollection of where we are: 1) we all agree cryptographic hash would likely not be a good choice 2) we agree the spec does not need to mandate any particular hash or length 3) it would help implementors if we gave advice of what a reasonable choice might be (in a non normative way) So far, I have not see a suggestion of what a good choice should be, I don't have a specific one to recommend, but I think the draft should propose a reasonable choice and a reasonable bit length because every implementer I know is going to do exactly whatever the draft shows in it's examples. On Oct 3, 2006, at 11:36 AM, Robert Sparks wrote: > There are other changes to the draft that I've agreed to make, so > there will be a new version (shortly). > > This question isn't pinned down yet though. The draft _doesn't_ > require any specific hash. It gives advice on a reasonable choice. > It goes further to characterize properties of other choices an > implementation might make, where it trips over this bit-count that > gave > people different kinds of heatburn. > > I propose just pulling the bit-length description and instead point > to the lack-of-collision property that folks need to take into > account. > We are already careful not to say "cryptographic", but I'll > probably add a comment making the lack-of-cryptographic-requirement > more explicit. > > RjS > > On Oct 3, 2006, at 1:21 PM, Dean Willis wrote: > >> Cullen Jennings wrote: >>> I don't think we should require any specific hash but I think it >>> would be nice to give implementors some advice on what might be a >>> reasonable choice. >> >> So does this mean we need a change to the draft, or did we decide >> to stand with the current text? >> >> -- >> 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 Oct 03 15:54:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqJv-0005hE-Ki; Tue, 03 Oct 2006 15:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqJt-0005h9-Tq for sip@ietf.org; Tue, 03 Oct 2006 15:52:49 -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 1GUqJs-00086v-IW for sip@ietf.org; Tue, 03 Oct 2006 15:52:49 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.4) with ESMTP id k93JqiGI014824 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 3 Oct 2006 14:52:45 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 14:52:44 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: SIP , Pete Cordell , 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 make this a little less vague - what the draft has right now is: > A common way to create the second part of the branch parameter value > when forking a request is to compute a hash over the > concatenation of > the Request-URI, any Route header field values used during > processing > the request and any other values used by the location service logic > while processing this request. An MD5 [RFC1321] hash expressed in > hexadecimal (base64 is not permissible for a token) is a reasonable > choice of a hash function. Any hash function chosen should have > the > property of very low probability of collision. Hashes resulting in > fewer than 128 bits are not recommended. I take it you are explicitly objecting to the statement that MD5 is a reasonable non-normatively specified choice? You have also clearly objected to 128 as a suggestion (The text does NOT mandate a length). RjS On Oct 3, 2006, at 2:34 PM, Cullen Jennings wrote: > > So my vague recollection of where we are: > > 1) we all agree cryptographic hash would likely not be a good choice > 2) we agree the spec does not need to mandate any particular hash > or length > 3) it would help implementors if we gave advice of what a > reasonable choice might be (in a non normative way) > > So far, I have not see a suggestion of what a good choice should > be, I don't have a specific one to recommend, but I think the draft > should propose a reasonable choice and a reasonable bit length > because every implementer I know is going to do exactly whatever > the draft shows in it's examples. > > > > On Oct 3, 2006, at 11:36 AM, Robert Sparks wrote: > >> There are other changes to the draft that I've agreed to make, so >> there will be a new version (shortly). >> >> This question isn't pinned down yet though. The draft _doesn't_ >> require any specific hash. It gives advice on a reasonable choice. >> It goes further to characterize properties of other choices an >> implementation might make, where it trips over this bit-count that >> gave >> people different kinds of heatburn. >> >> I propose just pulling the bit-length description and instead >> point to the lack-of-collision property that folks need to take >> into account. >> We are already careful not to say "cryptographic", but I'll >> probably add a comment making the lack-of-cryptographic-requirement >> more explicit. >> >> RjS >> >> On Oct 3, 2006, at 1:21 PM, Dean Willis wrote: >> >>> Cullen Jennings wrote: >>>> I don't think we should require any specific hash but I think it >>>> would be nice to give implementors some advice on what might be >>>> a reasonable choice. >>> >>> So does this mean we need a change to the draft, or did we decide >>> to stand with the current text? >>> >>> -- >>> 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 Oct 03 16:20:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqij-0006z4-5K; Tue, 03 Oct 2006 16:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUqig-0006xz-W4 for sip@ietf.org; Tue, 03 Oct 2006 16:18:26 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUqic-0003u8-Fx for sip@ietf.org; Tue, 03 Oct 2006 16:18:26 -0400 Received: (qmail 30278 invoked by uid 0); 3 Oct 2006 20:18:06 -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 < >; 3 Oct 2006 20:18:06 -0000 Message-ID: <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" , "IETF SIP List" References: <4522AFC5.10306@lucent.com> Subject: Re: [Sip] I-D on handling large UDP responses Date: Tue, 3 Oct 2006 22:18:15 +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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Three initial comments: 1) I would expect the main source of large responses to be the UAS sending a large response body. A transport switch does not necessarily imply that a large response will follow, in general I think those 140 responses will often be a waste of bandwidth. You could instead consider sending it just before the proxy is about to forward a response >MTU (1500 if unknown) over UDP, and then preferrably only when no 140/141 response from some downstream node was forwarded already (only possible to detect this for stateful proxies). 2) The current draft can result in cases where both a 140 and a 141 response are sent, this seems wasteful. When the UAS sends a response >1500 bytes over non-UDP, it does not necessarily imply that there will be a response >1500 bytes using UDP at some point. So if the proxy forwarding rule is changed per (1)above, the UAS should only send a 141 when it is sending over UDP itself (i.e. no inspection of the via chain needed). If there is a transition to UDP in the path beyond, a proxy will send 140 instead. This avoids duplicate 140/141 responses 3) Given the above, it could probably be done with only 1 response code. Proxies should then set the to-tag to the to-tag of the large response Regards, Jeroen ----- Original Message ----- From: "Vijay K. Gurbani" To: "IETF SIP List" Sent: Tuesday, October 03, 2006 8:45 PM Subject: [Sip] I-D on handling large UDP responses > Folks: An I-D on handling large UDP response has just been > submitted to the I-D editor. Until it appears in the archives, a > copy can be obtained from: > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html > > The draft suggests the use of 1xx-class responses to solve this > problem. > > Please look at the draft and provide comments and/or concerns. > > 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 Tue Oct 03 17:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUraS-0006Aa-Nb; Tue, 03 Oct 2006 17:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUraQ-00069I-Mu for sip@ietf.org; Tue, 03 Oct 2006 17:13:58 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUraM-0007HQ-8R for sip@ietf.org; Tue, 03 Oct 2006 17:13:58 -0400 Received: (qmail invoked by alias); 03 Oct 2006 21:13:52 -0000 Received: from p54984E4F.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.78.79] by mail.gmx.net (mp028) with SMTP; 03 Oct 2006 23:13:52 +0200 X-Authenticated: #29516787 Message-ID: <4522D292.50304@gmx.net> Date: Tue, 03 Oct 2006 23:13:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Progress of draft-ietf-sip-location-conveyance References: <5D1A7985295922448D5550C94DE2918051599A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918051599A@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, jmpolk@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 Hi Keith, I haven't read the updated draft version yet. Sorry. You might, however, not see reviews during this week since everyone who is active in the emergency service space (and therefore cares a lot about this document) is going to be at the SDO Emergency Service Coordination workshop (see http://www.ietf-ecrit.org/EmergencyWorkshop2006/). I plan to send a review early next week. Ciao Hannes Drage, Keith (Keith) schrieb: > We had the -04 version of this issued back in August, where we had a > fairly substantial rewrite by the authors. Does the rewrite improve the > document?? > > There have in the view of the WG chairs been sufficient comments made to > justify a new version before the IETF cutoff, and therefore we ask the > authors to produce that new version. We have been concerned at the > absence of list discussion so we would encourage SIP experts to review > this draft, so that some more work can be included in an updated > version. > > 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 Tue Oct 03 17:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrZH-0005FG-9h; Tue, 03 Oct 2006 17:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrZG-0005D3-3N for sip@ietf.org; Tue, 03 Oct 2006 17:12:46 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFrom sip-bounces@ietf.org Tue Oct 03 17:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUraS-0006Aa-Nb; Tue, 03 Oct 2006 17:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUraQ-00069I-Mu for sip@ietf.org; Tue, 03 Oct 2006 17:13:58 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GUraM-0007HQ-8R for sip@ietf.org; Tue, 03 Oct 2006 17:13:58 -0400 Received: (qmail invoked by alias); 03 Oct 2006 21:13:52 -0000 Received: from p54984E4F.dip.t-dialin.net (EHLO [192.168.2.35]) [84.152.78.79] by mail.gmx.net (mp028) with SMTP; 03 Oct 2006 23:13:52 +0200 X-Authenticated: #29516787 Message-ID: <4522D292.50304@gmx.net> Date: Tue, 03 Oct 2006 23:13:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Progress of draft-ietf-sip-location-conveyance References: <5D1A7985295922448D5550C94DE2918051599A@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918051599A@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, jmpolk@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 Hi Keith, I haven't read the updated draft version yet. Sorry. You might, however, not see reviews during this week since everyone who is active in the emergency service space (and therefore cares a lot about this document) is going to be at the SDO Emergency Service Coordination workshop (see http://www.ietf-ecrit.org/EmergencyWorkshop2006/). I plan to send a review early next week. Ciao Hannes Drage, Keith (Keith) schrieb: > We had the -04 version of this issued back in August, where we had a > fairly substantial rewrite by the authors. Does the rewrite improve the > document?? > > There have in the view of the WG chairs been sufficient comments made to > justify a new version before the IETF cutoff, and therefore we ask the > authors to produce that new version. We have been concerned at the > absence of list discussion so we would encourage SIP experts to review > this draft, so that some more work can be included in an updated > version. > > 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 Tue Oct 03 17:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrZH-0005FG-9h; Tue, 03 Oct 2006 17:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrZG-0005D3-3N for sip@ietf.org; Tue, 03 Oct 2006 17:12:46 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUrZE-0006Vk-OA for sip@ietf.org; Tue, 03 Oct 2006 17:12:46 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k93LCNYt002470; Tue, 3 Oct 2006 16:12:23 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 16:12:23 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 23:12:21 +0200 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] Outbound and SigComp Date: Tue, 3 Oct 2006 23:12:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE291805159B1@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and SigComp Thread-Index: AcbmZD4S3hAOyE29QoCJMZDz3FxVRQAy5Ehw From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "SIP" , "Rohan Mahy" , "Adam Roach" X-OriginalArrivalTime: 03 Oct 2006 21:12:21.0603 (UTC) FILETIME=[9DA6AB30:01C6E730] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an application protocol. Therefore in that document there is no indication that SigComp is designed for SIP, or for some other protocol. RFC 3486 (owned by SIP) specifies how SIP uses SigComp. On that basis, I would have thought that any group that intended their protocol to run over SigComp would need to define how it is used in those circumstances, as for usage over any other transport protocol.=20 In the absence of such a document, usage of SigComp by that protocol would be essentially proprietary. In summary therefore, I would suggest that as far as the RFCs are currently concerned, STUN is outside of SigComp, because noone in the STUN community has written a document to put it inside. Views? Regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 02 October 2006 21:46 > To: SIP; Rohan Mahy; Adam Roach > Subject: [Sip] Outbound and SigComp >=20 >=20 > A question I have been thinking about a little ... what=20 > happens when a UA is doing both outbound and sigcomp. Is it=20 > clear enough how this happiness? Is stun inside or outside=20 > the sigcomp, etc? Anyways, I just wanted to lodge this as an=20 > open issue - we probably should check that this is=20 > reasonable clear how to do this even if we don't have to say=20 > anything about it in outbound. >=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 UrZE-0006Vk-OA for sip@ietf.org; Tue, 03 Oct 2006 17:12:46 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k93LCNYt002470; Tue, 3 Oct 2006 16:12:23 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 16:12:23 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Oct 2006 23:12:21 +0200 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] Outbound and SigComp Date: Tue, 3 Oct 2006 23:12:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE291805159B1@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and SigComp Thread-Index: AcbmZD4S3hAOyE29QoCJMZDz3FxVRQAy5Ehw From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "SIP" , "Rohan Mahy" , "Adam Roach" X-OriginalArrivalTime: 03 Oct 2006 21:12:21.0603 (UTC) FILETIME=[9DA6AB30:01C6E730] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an application protocol. Therefore in that document there is no indication that SigComp is designed for SIP, or for some other protocol. RFC 3486 (owned by SIP) specifies how SIP uses SigComp. On that basis, I would have thought that any group that intended their protocol to run over SigComp would need to define how it is used in those circumstances, as for usage over any other transport protocol.=20 In the absence of such a document, usage of SigComp by that protocol would be essentially proprietary. In summary therefore, I would suggest that as far as the RFCs are currently concerned, STUN is outside of SigComp, because noone in the STUN community has written a document to put it inside. Views? Regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 02 October 2006 21:46 > To: SIP; Rohan Mahy; Adam Roach > Subject: [Sip] Outbound and SigComp >=20 >=20 > A question I have been thinking about a little ... what=20 > happens when a UA is doing both outbound and sigcomp. Is it=20 > clear enough how this happiness? Is stun inside or outside=20 > the sigcomp, etc? Anyways, I just wanted to lodge this as an=20 > open issue - we probably should check that this is=20 > reasonable clear how to do this even if we don't have to say=20 > anything about it in outbound. >=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 Oct 03 17:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrcn-0007Ai-Od; Tue, 03 Oct 2006 17:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrcn-0007Ad-10 for sip@ietf.org; Tue, 03 Oct 2006 17:16:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUrch-0000DZ-Ke for sip@ietf.org; Tue, 03 Oct 2006 17:16:25 -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 k93L9l500565; Tue, 3 Oct 2006 17:09:47 -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] I-D on handling large UDP responses Date: Tue, 3 Oct 2006 16:16:12 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60ECF3C3C@zrc2hxm2.corp.nortel.com> In-Reply-To: <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-index: AcbnKT7T7e48Y57tSiOA8BQb0iB9igAA1hSQ From: "Samir Srivastava" To: "Jeroen van Bemmel" , "Vijay K. Gurbani" , "IETF SIP List" X-Spam-Score: 0.0 (/) 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 I have some additional initial comment=20 =20 What will you do when 140/141 is lost? PRACK ?=20 As 141 is sent just before sending the final response , so cross over ? Forking with 141/140 in one branch, should CANCEL come into picture? Thx Samir > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Tuesday, October 03, 2006 1:18 PM > To: Vijay K. Gurbani; IETF SIP List > Subject: Re: [Sip] I-D on handling large UDP responses >=20 > Three initial comments: >=20 > 1) I would expect the main source of large responses to be the UAS sending > a > large response body. A transport switch does not necessarily imply that a > large response will follow, in general I think those 140 responses will > often be a waste of bandwidth. You could instead consider sending it just > before the proxy is about to forward a response >MTU (1500 if unknown) > over > UDP, and then preferrably only when no 140/141 response from some > downstream > node was forwarded already (only possible to detect this for stateful > proxies). >=20 > 2) The current draft can result in cases where both a 140 and a 141 > response > are sent, this seems wasteful. When the UAS sends a response >1500 bytes > over non-UDP, it does not necessarily imply that there will be a response > >1500 bytes using UDP at some point. So if the proxy forwarding rule is > changed per (1)above, the UAS should only send a 141 when it is sending > over > UDP itself (i.e. no inspection of the via chain needed). If there is a > transition to UDP in the path beyond, a proxy will send 140 instead. This > avoids duplicate 140/141 responses >=20 > 3) Given the above, it could probably be done with only 1 response code. > Proxies should then set the to-tag to the to-tag of the large response >=20 > Regards, >=20 > Jeroen >=20 > ----- Original Message ----- > From: "Vijay K. Gurbani" > To: "IETF SIP List" > Sent: Tuesday, October 03, 2006 8:45 PM > Subject: [Sip] I-D on handling large UDP responses >=20 >=20 > > Folks: An I-D on handling large UDP response has just been > > submitted to the I-D editor. Until it appears in the archives, a > > copy can be obtained from: > > > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp- > response/draft-gurbani-sip-large-udp-response-00.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp- > response/draft-gurbani-sip-large-udp-response-00.html > > > > The draft suggests the use of 1xx-class responses to solve this > > problem. > > > > Please look at the draft and provide comments and/or concerns. > > > > 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 >=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 Oct 03 17:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrvN-0005nW-UU; Tue, 03 Oct 2006 17:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUrvM-0005nM-Pv for sip@ietf.org; Tue, 03 Oct 2006 17:35:36 -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 1GUrvK-0005tc-BH for sip@ietf.org; Tue, 03 Oct 2006 17:35:36 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2006 14:35:33 -0700 X-IronPort-AV: i="4.09,251,1157353200"; d="scan'208"; a="444865569:sNHT2862972318" 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 k93LZWnH022538; Tue, 3 Oct 2006 14:35:32 -0700 Received: from [192.168.1.3] (sjc-vpn6-396.cisco.com [10.21.121.140]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k93LZRML027115; Tue, 3 Oct 2006 14:35:32 -0700 (PDT) In-Reply-To: <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@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: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 14:35:27 -0700 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1295; t=1159911332; x=1160775332; 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]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DAyadtlHzVE2lqPGk6mddYA9NTlg=3D; b=IykkXeE0+OVv9r0tZxKqOpXItmAudAlGTVJ9h/MNTOvLfWAOTHuXD7iIDW/oCFz+RyKzgQSS 7BMIL29NrXox1CtgCfD4rSbNL9pKmM9H2AJDMJ0vQeXqo3GzB7kbuw02; 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: SIP , Pete Cordell , 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 Oct 3, 2006, at 12:52 PM, Robert Sparks wrote: > > I take it you are explicitly objecting to the statement that MD5 is > a reasonable non-normatively specified choice? > You have also clearly objected to 128 as a suggestion (The text > does NOT mandate a length). > > RjS Yes - MD5 is a cryptographic hash and I thought we all agreed that use off cryptographic hash was not the best choice. If we think cryptographic hash ideas are a good idea, then we need to explain why. Using a cryptographic hash, even in an example, is a huge red flag for any security person reviewing this. The fact that we used this particular one which has significant security issues, is a even bigger issue. Partially I think MD5 is totally lame to use here because it is slow and offer no advantages over better things and partially I am trying to avoid any delays due to security review where someone points out we should not be using MD5 in new protocols. If the we can't figure out a reasonable hash to suggest, how should an implementer figure out what to use. I've been trying to say, I don't care what but don't choose a cryptographic one. If people have a good reason for wanting MD5, I'm glad to listen but I just had not heard the reason yet. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 17:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUs26-0001Z2-RA; Tue, 03 Oct 2006 17:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUs24-0001Yx-O6 for sip@ietf.org; Tue, 03 Oct 2006 17:42:32 -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 1GUs22-0007o9-C9 for sip@ietf.org; Tue, 03 Oct 2006 17:42:32 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.4) with ESMTP id k93LgQSI025747 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 3 Oct 2006 16:42:27 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@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 Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 16:42:26 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: SIP , Pete Cordell , 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 The only reason it is here is that it was what was called out for this job in 3261. So - Give me an alternative. RjS On Oct 3, 2006, at 4:35 PM, Cullen Jennings wrote: > > On Oct 3, 2006, at 12:52 PM, Robert Sparks wrote: > >> >> I take it you are explicitly objecting to the statement that MD5 >> is a reasonable non-normatively specified choice? >> You have also clearly objected to 128 as a suggestion (The text >> does NOT mandate a length). >> >> RjS > > Yes - MD5 is a cryptographic hash and I thought we all agreed that > use off cryptographic hash was not the best choice. If we think > cryptographic hash ideas are a good idea, then we need to explain why. > > Using a cryptographic hash, even in an example, is a huge red flag > for any security person reviewing this. The fact that we used this > particular one which has significant security issues, is a even > bigger issue. Partially I think MD5 is totally lame to use here > because it is slow and offer no advantages over better things and > partially I am trying to avoid any delays due to security review > where someone points out we should not be using MD5 in new > protocols. If the we can't figure out a reasonable hash to suggest, > how should an implementer figure out what to use. I've been trying > to say, I don't care what but don't choose a cryptographic one. If > people have a good reason for wanting MD5, I'm glad to listen but I > just had not heard the reason yet. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 18:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsNh-0001Qb-1c; Tue, 03 Oct 2006 18:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUsNf-0001QW-9R for sip@ietf.org; Tue, 03 Oct 2006 18:04:51 -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 1GUsNd-0008Nm-Uz for sip@ietf.org; Tue, 03 Oct 2006 18:04:51 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.4) with ESMTP id k93M4muE030406 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 3 Oct 2006 17:04:48 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CF95D3B-071E-4C5C-81C3-307273E03B94@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Tue, 3 Oct 2006 17:04:47 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Cullen Jennings , SIP , Pete Cordell , 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 - based on an off-line conversation with cullen, lets suggest CRC32 as specified in RFC3309. If nobody screams, that's what the next rev will say. RjS On Oct 3, 2006, at 4:42 PM, Robert Sparks wrote: > The only reason it is here is that it was what was called out for > this job in 3261. > > So - Give me an alternative. > > RjS > > On Oct 3, 2006, at 4:35 PM, Cullen Jennings wrote: > >> >> On Oct 3, 2006, at 12:52 PM, Robert Sparks wrote: >> >>> >>> I take it you are explicitly objecting to the statement that MD5 >>> is a reasonable non-normatively specified choice? >>> You have also clearly objected to 128 as a suggestion (The text >>> does NOT mandate a length). >>> >>> RjS >> >> Yes - MD5 is a cryptographic hash and I thought we all agreed that >> use off cryptographic hash was not the best choice. If we think >> cryptographic hash ideas are a good idea, then we need to explain >> why. >> >> Using a cryptographic hash, even in an example, is a huge red flag >> for any security person reviewing this. The fact that we used this >> particular one which has significant security issues, is a even >> bigger issue. Partially I think MD5 is totally lame to use here >> because it is slow and offer no advantages over better things and >> partially I am trying to avoid any delays due to security review >> where someone points out we should not be using MD5 in new >> protocols. If the we can't figure out a reasonable hash to >> suggest, how should an implementer figure out what to use. I've >> been trying to say, I don't care what but don't choose a >> cryptographic one. If people have a good reason for wanting MD5, >> I'm glad to listen but I just had not heard the reason yet. >> >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 03 19:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtTg-0006gY-Ck; Tue, 03 Oct 2006 19:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUtTe-0006f0-4j for sip@ietf.org; Tue, 03 Oct 2006 19:15:06 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUtR9-0006wt-Os for sip@ietf.org; Tue, 03 Oct 2006 19:12:38 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 0D8CC36C4A0; Tue, 3 Oct 2006 16:12:24 -0700 (PDT) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 7A97136C18C; Tue, 3 Oct 2006 16:12:23 -0700 (PDT) Message-ID: <4522EE57.2020107@acm.org> Date: Tue, 03 Oct 2006 16:12:23 -0700 From: Marc Petit-Huguenin User-Agent: Thunderbird 1.5.0.7 (X11/20060928) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> In-Reply-To: <4522AFC5.10306@lucent.com> Content-Type: text/plain; charset=ISO-8859-1 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 I was working on a different solution to the same problem. This solution can be seen as an extension of what you are proposing in section 4.1. Until the I-D appears in the archives, a copy is available here: http://marc.petit-huguenin.org/draft-petithuguenin-sip-fragmentation-responses-00.txt Vijay K. Gurbani wrote: > Folks: An I-D on handling large UDP response has just been > submitted to the I-D editor. Until it appears in the archives, a > copy can be obtained from: > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html > > > The draft suggests the use of 1xx-class responses to solve this > problem. > > Please look at the draft and provide comments and/or concerns. > > Thank you. > > - vijay -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.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 Oct 03 22:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwcK-0002F3-C8; Tue, 03 Oct 2006 22:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwcJ-0002Ex-99 for sip@ietf.org; Tue, 03 Oct 2006 22:36:15 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwcI-00085p-11 for sip@ietf.org; Tue, 03 Oct 2006 22:36:15 -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 k942aDKU008398; Tue, 3 Oct 2006 21:36:13 -0500 (CDT) Received: from [135.244.32.137] (vkg.lra.lucent.com [135.244.32.137]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k942aDk09731; Tue, 3 Oct 2006 21:36:13 -0500 (CDT) Message-ID: <45231E1D.9080407@lucent.com> Date: Tue, 03 Oct 2006 21:36:13 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] I-D on handling large UDP responses References: <62B9B0847CC47543B6B3B5E26BD268E60ECF3C3C@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60ECF3C3C@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: 8b30eb7682a596edff707698f4a80f7d 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 Samir Srivastava wrote: > I have some additional initial comment Samir: Thanks for your comments. > What will you do when 140/141 is lost? PRACK ? We thought of PRACK, but in the end decided not to use it. It makes the machinery too complex. Yes, there is a chance that the 14x response is lost, or experiences excessive queuing delays. But, dropped packets are not the norm in today's networks (I would hope). > As 141 is sent just before sending the final response , so cross over ? If the final response arrives unscathed, then the 14x will have no impact on the state machine when it is received later. If on the other hand, the final response is mangled, then when the UAC gets the 14x, it has some semblance of what is going on... > Forking with 141/140 in one branch, should CANCEL come into picture? This is no different than other provisional responses and their interaction with CANCEL. If a CANCEL is received after the 14x is sent out but before a final response has been sent out, then the CANCEL takes precedence -- the 141 does not foreshadow a 2xx final response, it could just as well be a 487. Otherwise, if a CANCEL is received after the final response is sent out, then the CANCEL has no effect on the state machinery. Probably worth pointing out in the next revision of the draft. 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 Oct 03 22:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwcD-0002A7-Ei; Tue, 03 Oct 2006 22:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwcB-00024y-V1 for sip@ietf.org; Tue, 03 Oct 2006 22:36:07 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwc9-00084A-LP for sip@ietf.org; Tue, 03 Oct 2006 22:36:07 -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 k942ZwEY008210; Tue, 3 Oct 2006 21:35:58 -0500 (CDT) Received: from [135.244.32.137] (vkg.lra.lucent.com [135.244.32.137]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k942Zwk09555; Tue, 3 Oct 2006 21:35:58 -0500 (CDT) Message-ID: <45231E0E.80803@lucent.com> Date: Tue, 03 Oct 2006 21:35:58 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> In-Reply-To: <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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: > Three initial comments: Jeroen: Thanks. Please see inline. > 1) I would expect the main source of large responses to be the UAS > sending a large response body. Forking coupled with response aggregation of 401/407 is another reason why the responses balloon. R-R headers added with all kinds of state is yet another. > A transport switch does not necessarily > imply that a large response will follow, in general I think those 140 > responses will often be a waste of bandwidth. Possibly so; but all the same, I think they can be a valuable feed- back to the UAC. One thing we have struggled with in the SIPS debate is that there is no backwards feedback to the UAC if a downgrade occurs. Here, there is some explicit feedback that the UAC may find pertinent. > You could instead consider > sending it just before the proxy is about to forward a response >MTU > (1500 if unknown) over UDP, and then preferrably only when no 140/141 > response from some downstream node was forwarded already (only possible > to detect this for stateful proxies). True. > 2) The current draft can result in cases where both a 140 and a 141 > response are sent, this seems wasteful. When the UAS sends a response > >1500 bytes over non-UDP, it does not necessarily imply that there will > be a response >1500 bytes using UDP at some point. I am unable to follow the last sentence ... sorry. Can you amplify? > So if the proxy > forwarding rule is changed per (1)above, the UAS should only send a 141 > when it is sending over UDP itself (i.e. no inspection of the via chain > needed). Having the UAS inspect the Via chain for a UDP link assures that the 141 is sent out only if the response will traverse a UDP link some time before reaching its final destination; i.e., the UAS may have got the request over TCP, but there is some upstream entity that used UDP to send the request downstream. > If there is a transition to UDP in the path beyond, a proxy > will send 140 instead. This avoids duplicate 140/141 responses If a UAS sends a final response, there will not be any transition in the path beyond the UAS... 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 Oct 03 22:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwgH-00050w-SR; Tue, 03 Oct 2006 22:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUwgG-00050L-G9 for sip@ietf.org; Tue, 03 Oct 2006 22:40:20 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUwgF-0000HS-2J for sip@ietf.org; Tue, 03 Oct 2006 22:40:20 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 03 Oct 2006 19:37:58 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208,217"; a="589835022:sNHT120612710" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:40:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Oct 2006 19:40:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Apple iChat AV documents Thread-Index: AcbnXmsZNiMGPdirSFGZ1npUk9QuDA== From: "Anil Bollineni" To: X-OriginalArrivalTime: 04 Oct 2006 02:40:14.0500 (UTC) FILETIME=[6B9C8640:01C6E75E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org Subject: [Sip] Apple iChat AV documents X-BeenThere: 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="===============0811037818==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0811037818== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E75E.6B183D24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E75E.6B183D24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Does any one know where can I find document about Apple iChat is using SIP to communicate with another iChat? =20 Specifically if iChat is deployed before firewall, then what ports need to open in the firewall the make iChat work.=20 I have found the document at http://docs.info.apple.com/article.html?artnum=3D93208, specifying the ports to open for iChat. I understand standard ports like 5060 and media ports (16384-16403) are negotiated in SIP message.=20 I could not figure out how the ports like 5190, 5297, 5298, 5678 mentioned will be exchanged between iChat applications. Are they pre-configured or are any special headers are used in SIP by iChat for the above ports? =20 Thanks a lot, =20 -Anil ------_=_NextPart_001_01C6E75E.6B183D24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Does any one know where can I find document about = Apple iChat is using SIP to communicate with another = iChat?

 

Specifically if iChat is deployed before firewall, = then what ports need to open in the firewall the make iChat work. =

I have found the document at http://d= ocs.info.apple.com/article.html?artnum=3D93208, specifying the ports to open for iChat.

I understand standard ports like 5060 and media ports = (16384-16403) are negotiated in SIP message.

I could not figure out how the ports like 5190, 5297, = 5298, 5678 mentioned will be exchanged between iChat = applications.

Are they pre-configured or are any special headers = are used in SIP by iChat for the above ports?

 

Thanks a lot,

 

-Anil

------_=_NextPart_001_01C6E75E.6B183D24-- --===============0811037818== 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 --===============0811037818==-- From sip-bounces@ietf.org Tue Oct 03 23:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx7T-00083o-2c; Tue, 03 Oct 2006 23:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx7I-0007l2-1D for sip@ietf.org; Tue, 03 Oct 2006 23:08:16 -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 1GUwxw-0002fH-0q for sip@ietf.org; Tue, 03 Oct 2006 22:58:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2006 19:58:35 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="344486251:sNHT55170986" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k942wZM0020611; Tue, 3 Oct 2006 19:58:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k942wWJr014606; Tue, 3 Oct 2006 19:58:35 -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); Tue, 3 Oct 2006 19:58:33 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 19:58:32 -0700 Message-ID: <45232357.3030100@cisco.com> Date: Tue, 03 Oct 2006 22:58:31 -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: "Drage, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE291804684A3@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291804684A3@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 02:58:32.0828 (UTC) FILETIME=[FA4413C0:01C6E760] DKIM-Signature: a=rsa-sha1; q=dns; l=3094; t=1159930715; x=1160794715; c=relaxed/simple; s=sjdkim3002; 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=20Comments=20on=20draft-ietf-sip-acr-code-02; X=v=3Dcisco.com=3B=20h=3D13Q7L30VWi+VDCFkBTMfN8XWc50=3D; b=k7MvktUZ+ylwBikPHv69VKUZqkQFbYMg02p3dMw6mXtm3JiQMGMOQ+o4g7Kb8qj7CCNnfmuZ My884fRcmCSs1uxh9NaVpRG4SFmSh+v2hszE9EY0sqeEyCkLL18UeDT/; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org Subject: [Sip] Re: Comments on draft-ietf-sip-acr-code-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Drage, Keith (Keith) wrote: > I have reviewed the entire draft. > > 1) In section 3, I wondered if it would be appropriate to have a > couple more key statements of when it does not apply. > > For example, if we are using RFC 4474, and the recipient of the SIP > request has received the identity but has been unable to obtain the > certificate for the identity, then the proposed 433 response code is > inappropriate, and indeed RFC 4474 specifies response codes for this > situation, which should always be used in preference. OK. I added this: In addition, requests where the identity of the requestor cannot be determined or validated, but it is not a consequence of an explicit action on the part of the requestor, are not consider anonymous. For example, if a request contains a non-anonymous From header field, along with the Identity and Identity-Info header fields , but the certificate could not be obtained from the reference in the Identity-Info header field, it is not considered an anonymous request, and the 433 response code SHOULD NOT be used. > > 2) Section 3. > > o 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. > > I have noted the ongoing discussion on this, and certainly my > interpretation was that the "header" value in the Privacy header could > cover the P-Asserted-Identity header. However I think we should avoid > that this draft attempts to fix unclear specification in RFC 3323 and > (and possibly RFC 3325). I would therefore suggest that we strike the > offending words. Fine. In the interests of forward progress I will strike the offending sentence. > > 3) Section 4. > > This section seems to be the one that should talk about dialog usage. > While identities are usefully provided in the initial transaction in a > dialog, there is nothing that prevents them being exchanged in later > transactions, and indeed for the support of some services it is > necessary, as the identity will have changed. > > The document should indicate the effect of receiving a 433 response to a > request sent within an existing dialog, where the implementation does > support this extension, which I assume should be the defauly 4xx > response treatment. I've added the following: Receipt of a 433 response to a mid-dialog request SHOULD NOT cause the dialog to terminate, and SHOULD NOT cause the specific usage of that dialog to terminate . 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 Oct 03 23:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx9m-0001H2-K3; Tue, 03 Oct 2006 23:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUx9k-0001GH-JU for sip@ietf.org; Tue, 03 Oct 2006 23:10:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUx9i-0004nt-48 for sip@ietf.org; Tue, 03 Oct 2006 23:10:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2006 20:10:45 -0700 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 k943AjXc009308 for ; Tue, 3 Oct 2006 20:10:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k943Ajql001762 for ; Tue, 3 Oct 2006 20:10:45 -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); Tue, 3 Oct 2006 20:10:45 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 20:10:45 -0700 Message-ID: <45232634.5030109@cisco.com> Date: Tue, 03 Oct 2006 23:10:44 -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: Paul Kyzivat Subject: Re: [Sip] Re: SIP WGLC Draft draft-ietf-sip-acr-code-02.txt References: <85108216918A984C8C60172D7C84770A56F689@S4DE8PSAAGO.mitte.t-com.de> <45099F5D.8000904@softarmor.com> <4509C6E8.6080503@ntt-at.com> <450A2D66.2020209@cisco.com> <450AA88B.8010403@cisco.com> <450B16AB.5050409@cisco.com> In-Reply-To: <450B16AB.5050409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 03:10:45.0221 (UTC) FILETIME=[AECE6150:01C6E762] DKIM-Signature: a=rsa-sha1; q=dns; l=3877; t=1159931445; x=1160795445; c=relaxed/simple; s=sjdkim2002; 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]=20Re=3A=20SIP=20WGLC=20=20Draft=20draft-ietf-sip-acr-code- 02.txt; X=v=3Dcisco.com=3B=20h=3Dv2T5uTw5MXQnSSg9Oj4nkUwODy0=3D; b=2JZravCJH+rIotByO9YBO8h0ipJjoNuZOzjhWmTobng9GhBsLlU+AUNrbQAvJY55kF2sKpAO bZyX6l8nGVbAaf397oSA9tkcEgK+16aolS8K/0RGSIb4XypPcPaozhqt; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 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. Replies inline. Paul Kyzivat wrote: > Here are some comments based on a fresh read of this draft. > > Paul > > * Intro, second paragraph - typo: > > s/to explicitly to indicate/to explicitly indicate/ fixed. > > * Section 3: > > "A server acting on behalf of the called party, such as the UAS or a > proxy in their domain, MAY generate a 433 ..." > > Is there any reason this is restricted to servers acting on behalf of > the called party? While that is where is is likely to be most useful, I > can see no reason to prevent a server acting for the calling party, or > for an intermediary, from using this. I suppose a proxy in the originating domain could have a policy which prohibits its users from making anonymous calls, in which case 433 is appropriate. I've reworded to: A server (generally acting on behalf of the called party, though this need not be the case) MAY generate a 433 (Anonymity Disallowed) response when it receives an anonymous request, and the server refuses to fulfill the request because the requestor is anonymous. A request is considered anonymous when the identity of the originator of the request has been explicitly withheld by the originator. This occurs in any one of the following cases: > > Regarding the controversy over what values of the privacy header might > justify this response: Why don't we just say that any value in the > Privacy header other than "none" or "critical" *may* be considered > grounds for returning this response? I've just removed the bit about session and header. Its clear that user and id do imply anonymity so let us state what we do know. > > "It is important to note that lack of a P-Asserted-Identity header > field, in and of itself, is not an indication of anonymity. Even > though a Privacy header field value of 'id' will cause the removal of > the P-Asserted-Identity header field, there is no way to > differentiate this case from one in which P-Asserted-Identity was not > supported by the originating domain. As a consequence, a request > without a P-Asserted-Identity is considered anonymous only when there > is some other indication of this, such as a From header field with a > display name of 'Anonymous'." > > I'm not clear whether this is intended to have normative strength or > not. I think not. I think so; we're making statements (at SHOULD strength, I think) about what constitutes 'anonymous'. So, I added a statement up front that says a request SHOULD be anonymous when explicitly indicated as such, and that includes the cases listed. Then, in the text you cite above, I said that lack of p-asserted-id by itself SHOULD NOT be considered anonymous. If so, it would be better to make that explicit by > making it a note or something. I think there is good logic here, but it > may not suit everyone's policy. And I can see no reason to require this > policy. If someone has the misfortune to be calling on a path that can't > deliver the identity then they will not be able to successfully complete > the call even if they are not overtly blocking their identity. But that > is life - it is what the callee desires. We write SHOULD for these reasons; you can override with good raeson but based on our expertise this is the right thing to do. I think its clear that as currently specified, lack of P-aseerted-id alone is NOT an anonymous request. -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 Oct 03 23:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUxPd-0003Xz-Q3; Tue, 03 Oct 2006 23:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUxPc-0003Xs-Dk for sip@ietf.org; Tue, 03 Oct 2006 23:27:12 -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 1GUxPb-0000ck-2X for sip@ietf.org; Tue, 03 Oct 2006 23:27:12 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2006 20:27:11 -0700 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 k943RAd0019546; Tue, 3 Oct 2006 20:27:10 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k943RAql007915; Tue, 3 Oct 2006 20:27:10 -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); Tue, 3 Oct 2006 20:27:10 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 20:27:09 -0700 Message-ID: <45232A0C.3050000@cisco.com> Date: Tue, 03 Oct 2006 23:27:08 -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: "Elwell, John" Subject: Re: [Sip] WGLC: draft-ietf-sip-acr-code References: <50B1CBA96870A34799A506B2313F266709C88371@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266709C88371@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 03:27:10.0077 (UTC) FILETIME=[F9D37AD0:01C6E764] DKIM-Signature: a=rsa-sha1; q=dns; l=2462; t=1159932430; x=1160796430; c=relaxed/simple; s=sjdkim2002; 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]=20WGLC=3A=20draft-ietf-sip-acr-code; X=v=3Dcisco.com=3B=20h=3DnxIjVrrqRrBbgPNnfPbRyBjbeJo=3D; b=br2spXwLwouJI8anovEgmU9uAlRbYzYTrifxU58W83vFnQoX4Wh2gy3HZhGhNz+U/OJqfRB1 iiwuBbpeYs1u53Tu8yyQ/F6q7nf7KnBEgqu0QgwdeMwXr4u7eSMIeKFZ; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > 1. Section 1, first paragraph. Would it be beneficial to mention the > anonymity provisions of RFC 4474, i.e., a signature that says the request > originated at the domain indicated in the From header field but the specific > user is not disclosed? If so, then RFC 4474 would need to be added as an > informative reference. I think its worth mentioning 4474 but not here; rather, its worth clarifying later in the document that if the From contains an indication of an anonymous URI within a domain, yet identity is still there and validated, the request is anonymous. The spec now reads: The From or P-Asserted-Identity header field contains a URI which has an explicit indication that it is anonymous. One such example of a mechanism that would meet this criteria is . This criteria is true even if the request has a validated Identity header field , which can be used in concert with anonymized From header fields. > > 2. Section 1, 2nd paragraph "that reason phrase is not useful for automata". > Add "or where the caller speaks a different language". changed. > > 3. I am not sure where it fits, but should there be mention of the HERFP > problem, i.e. 433 being masked by some other response code at a forking > proxy? This is a generic problem with 4xx as we know; I don't see what usefully can be said here. > > NITS: > 4. Section 4, first paragraph: "if user continues" - change to "if the user > continues". > > 5. Section 4, second paragraph: "A UAC the does not understand" - change to > "A UAC that does not understand". > > 6. Section 5: "the server refused the fulfill" - change to "the server > refused to fulfill". > > 7. Section 7: "an request" - change to "a request". > > 8. Section 7, second paragraph "this has the desired effect" - change to > "anonymous call rejection has the desired effect". ("this" looks like it > refers to the fact that telemarketeers frequently withhold their identity). all fixed. -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 Oct 03 23:55:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUxo9-0003Cm-UK; Tue, 03 Oct 2006 23:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUxo8-0003Cg-QC for sip@ietf.org; Tue, 03 Oct 2006 23:52:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUxo6-0005Pm-Db for sip@ietf.org; Tue, 03 Oct 2006 23:52:32 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 20:52:30 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="327902719:sNHT55111264" 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 k943qSrK004131; Tue, 3 Oct 2006 20:52:28 -0700 Received: from [192.168.1.3] (sjc-vpn6-709.cisco.com [10.21.122.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k943qSML013754; Tue, 3 Oct 2006 20:52:28 -0700 (PDT) In-Reply-To: <451C423A.4060106@cisco.com> References: <33D71F0FC0684C4C8A3BB76989EDED9C028BE3CE@eesmdmw020.eemea.ericsson.se> <008301c6dc9f$5aa28930$0601a8c0@BEMBUSTER> <451B3ACB.9010009@cisco.com> <20060928063849.qfp2hrxqw2f4wwsw@webmail.versatel.nl> <451C423A.4060106@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FBC870D-F138-4996-BB70-E5B77EF288B4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] GRUU and Anonymity Date: Tue, 3 Oct 2006 20:52:29 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=2814; t=1159933948; x=1160797948; 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]=20GRUU=20and=20Anonymity; X=v=3Dcisco.com=3B=20h=3DZ39bG2oCOJMMVzcbRJS9Pt33/8A=3D; b=sWI6Ie1sAeO98Q5xTWloE9p7Zy+jW61GOVEwwOBOdLsHeUqmJNzvObJ7jiSGFzRJd7+OnHua YKsTVSbqRq8Iq50shA0A+JeAqAGyw8lj2iWK0ktmWD21i5P1FhMNIGwq; 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: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "sip@ietf.org" , "Jesus Javier Arauz \(MI/EEM\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Jonathan here and I will add that in many practical cases, the IP addresses are somewhat changing via DHCP - in these cases the IP address usually does not locate a UA down to a individual person level. In 3261 today, you might get a call that is Anonymous but has an IP traceable to comcast in Bay area. Now I admit you can construct cases where you only know one person who lives in the US so that identifies the person but for the most part, this level of protection does a much better than nothing job of protecting who the exact individual is. I wish we had something better than 3261, and I think we should keep working on something better, but given how difficult it is, I am perfectly happy if we can make sure that GRUU is not worse than 3261 and get it finished. Cullen On Sep 28, 2006, at 2:44 PM, Jonathan Rosenberg wrote: > > > jbemmel@zonnet.nl wrote: > >> Jonathan, >> In that case, I personally would prefer to do it properly in a >> separate draft, and for GRUU say something like: "GRUU provides >> the equivalent of a fixed public IP address. > > But its worse than that. Today, it will give you a GRUU which is > personally identifying you. An IP address is more of a pseudonym > and is useful primary as a correlator. Thats the issue; GRUU makes > things WORSE than rfc3261. > > >> All privacy issues associated with the use of such an address also >> apply to GRUUs. If additional privacy protection is required, it >> is recommended to use a privacy service [ref]" > > While we could merely suggest usage of a privacy service, it would > imply that a b2bua function is required for any kind of anonymity > services with gruu enabled. That is a tough pill to swallow. > >> I don't see much added value in providing something that addresses >> the issues "kind of half". By adding a relatively simple feature >> now, we would create complexity in terms of the number of >> available options/alternatives later. > > Its not 'kind of half' - its addressing them exactly like RFC 3261 > does. > > -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 Wed Oct 04 00:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyDD-0003aB-1z; Wed, 04 Oct 2006 00:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyDB-0003a2-Nk for sip@ietf.org; Wed, 04 Oct 2006 00:18:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUyDA-0000A2-E0 for sip@ietf.org; Wed, 04 Oct 2006 00:18:25 -0400 Received: from [10.89.16.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k943LQZL014966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Oct 2006 22:21:26 -0500 Message-ID: <452335C4.4090305@softarmor.com> Date: Tue, 03 Oct 2006 23:17:08 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU and Grid alternative References: <451A10FD.8040809@cisco.com> In-Reply-To: <451A10FD.8040809@cisco.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 Jonathan Rosenberg wrote: > The basic idea would be to remove the grid mechanism entirely from the > gruu draft. Instead, a separate specification would be developed which > would allow for loose routing to apply to user agents. So, consider a UA > which registers. It would include a contact and a Supported header field > with the value "ua-route". The registrar, assuming it understands this, > notes that the UA supports UA loose routing and stores the contact. When > an incoming call arrives for the AOR, rather than rewriting the R-URI > with the registered contact, it pushes the registered contact into a > Route header and leaves the R-URI alone (assuming the registered UA > supports this mechanism). I'd like to go on record as saying that this apparently resolves one of the Great Fundamental Evils of SIP that I've so often sermonized and thereby either makes me happy and fulfilled or leaves me looking for something else to whine about. In either case, it is a very good fix, and long overdue. -- 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 Oct 04 00:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyQT-0005Ie-F5; Wed, 04 Oct 2006 00:32:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUyQS-0005IZ-ER for sip@ietf.org; Wed, 04 Oct 2006 00:32:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUyQR-0002bn-67 for sip@ietf.org; Wed, 04 Oct 2006 00:32:08 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2006 21:32:07 -0700 X-IronPort-AV: i="4.09,252,1157353200"; d="scan'208"; a="327911653:sNHT54466008" 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 k944W6WP009374; Tue, 3 Oct 2006 21:32:06 -0700 Received: from [192.168.1.3] (sjc-vpn6-709.cisco.com [10.21.122.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k944Vrid001662; Tue, 3 Oct 2006 21:32:02 -0700 (PDT) In-Reply-To: <4522B38D.3090407@softarmor.com> References: <4522AFC5.10306@lucent.com> <4522B38D.3090407@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <288F3F91-796E-4045-9D32-187A52F58B72@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D on handling large UDP responses Date: Tue, 3 Oct 2006 21:31:54 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=365; t=1159936326; x=1160800326; 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]=20I-D=20on=20handling=20large=20UDP=20responses; X=v=3Dcisco.com=3B=20h=3Dp2g7B6dieyWGz10ZG4hh3GlVpTU=3D; b=aoJsPyq+g8jMyLgGf3AWS4sHkWX3QPHinG/kvdR+XGWI3zbzi1Jus4RYplj6d4Ylp1Oh22FA o9nd0kynxeASlFyugWHnJAX2cZMedCcr8QbFieM0RC0itqyQCVgqK3eo; 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: 30ac594df0e66ffa5a93eb4c48bcb014 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 On Oct 3, 2006, at 12:01 PM, Dean Willis wrote: > So, are we stuck on advancing the hop-limit-diagnostics draft until > we advance something like this draft? At the last IETF, I think Vijay, Scott and I had come up with a way to deal with hop-limit-diag without doing this but I have no objections if folks want to have it wait for something like 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 Oct 04 01:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUz7Y-00017p-Ew; Wed, 04 Oct 2006 01:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUz7X-00017k-D5 for sip@ietf.org; Wed, 04 Oct 2006 01:16:39 -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 1GUz7V-0006CZ-1r for sip@ietf.org; Wed, 04 Oct 2006 01:16:39 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2006 22:16:37 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k945GahW002238 for ; Tue, 3 Oct 2006 22:16:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k945GaYp024668 for ; Tue, 3 Oct 2006 22:16:36 -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); Tue, 3 Oct 2006 22:16:36 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 22:16:35 -0700 Message-ID: <452343B3.1040900@cisco.com> Date: Wed, 04 Oct 2006 01:16: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 05:16:36.0020 (UTC) FILETIME=[436EDF40:01C6E774] DKIM-Signature: a=rsa-sha1; q=dns; l=2099; t=1159938996; x=1160802996; 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:Updated=20acr-code=20specification; X=v=3Dcisco.com=3B=20h=3DU/E2FM5nbxWCxV/yzSOve3eAFqY=3D; b=lYOuTXDjcWWwLtEtAZInAVwIm8O7Ms3nd27mOYTArC5uVWusLUHM6D7RGMn36mogiafoY02d ViyNob1l816NMugXsoPkMF2Kx6Wxh2b4tD7v8CIuMwQJV7EVz0XZHg2l; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sip] Updated acr-code specification X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted an update to acr-code based on comments received during WGLC. Until the draft appaers in the archives, you can pick up a copy here: http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-03.txt Here are the diffs: * if a UAC gets a 433, it MUST NOT retry without anonymity unless user has given permission (used to be SHOULD NOT) * added this text to the server behavior section: In addition, requests where the identity of the requestor cannot be determined or validated, but it is not a consequence of an explicit action on the part of the requestor, are not consider anonymous. For example, if a request contains a non-anonymous From header field, along with the Identity and Identity-Info header fields , but the certificate could not be obtained from the reference in the Identity-Info header field, it is not considered an anonymous request, and the 433 response code SHOULD NOT be used. * removed mention of 'header' and 'session' privacy as being anonymous, since there was rough consensus that this needed to be clarified elsewhere. * clarified the impact of 433 when received in a mid-dialog response - no termiantion of the dialog or usages on the dialog. * softened wording that seemed to imply only a proxy/UAS in the terminating side could use 433. * added SHOULD strengths to criteria for definining anonymity and SHOULD NOT for the case where p-a-id is absent and nothing else in the request says its anonymous * clarified that requests are still anonymous if a validated Identity is there and the From indicates anonymous * changed reference from rosenberg-identity-privacy to rosenberg-id-coexistence 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 Wed Oct 04 02:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0XO-00074m-BA; Wed, 04 Oct 2006 02:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0XN-00074h-32 for sip@ietf.org; Wed, 04 Oct 2006 02:47:25 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0XL-0007fR-KQ for sip@ietf.org; Wed, 04 Oct 2006 02:47:25 -0400 Received: (qmail 6788 invoked by uid 0); 4 Oct 2006 06:47:10 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Oct 2006 06:47:10 -0000 Message-ID: <001c01c6e780$eaae9d20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <45231E0E.80803@lucent.com> Subject: Re: [Sip] I-D on handling large UDP responses Date: Wed, 4 Oct 2006 08:47:10 +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: 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 Vijay, see inline Regards, Jeroen ----- Original Message ----- From: "Vijay K. Gurbani" To: "Jeroen van Bemmel" Cc: "IETF SIP List" Sent: Wednesday, October 04, 2006 4:35 AM Subject: Re: [Sip] I-D on handling large UDP responses > Jeroen van Bemmel wrote: >> Three initial comments: > > Jeroen: Thanks. Please see inline. > >> 1) I would expect the main source of large responses to be the UAS >> sending a large response body. > > Forking coupled with response aggregation of 401/407 is another > reason why the responses balloon. R-R headers added with all kinds > of state is yet another. > I think it would be good if the draft provided some text on this. For starters: the current draft does not help in case of large responses due to forking+401/407 aggregation as you describe here. Another reason to have the proxy send 140 just before it forwards a large response. >> A transport switch does not necessarily imply that a large response will >> follow, in general I think those 140 responses will often be a waste of >> bandwidth. > > Possibly so; but all the same, I think they can be a valuable feed- > back to the UAC. One thing we have struggled with in the SIPS > debate is that there is no backwards feedback to the UAC if a > downgrade occurs. Here, there is some explicit feedback that the > UAC may find pertinent. > There may be situations where this is valuable feedback. However, it seems orthogonal to large UDP responses (i.e. solution for different problem) >> You could instead consider sending it just before the proxy is about to >> forward a response >MTU (1500 if unknown) over UDP, and then preferrably >> only when no 140/141 response from some downstream node was forwarded >> already (only possible to detect this for stateful proxies). > > True. > >> 2) The current draft can result in cases where both a 140 and a 141 >> response are sent, this seems wasteful. When the UAS sends a response >> >1500 bytes over non-UDP, it does not necessarily imply that there will >> be a response >1500 bytes using UDP at some point. > > I am unable to follow the last sentence ... sorry. Can you > amplify? > Suppose the UAS sends a response of 1510 bytes over TCP. The next upstream proxy removes the topmost Via, making the response smaller than 1500 bytes, and then forwards it over UDP. In this case there is no response > 1500 travelling over UDP, even though the UAS sent a response larger than 1500 bytes and there is UDP in the chain >> So if the proxy forwarding rule is changed per (1)above, the UAS should >> only send a 141 when it is sending over UDP itself (i.e. no inspection of >> the via chain needed). > > Having the UAS inspect the Via chain for a UDP link assures that > the 141 is sent out only if the response will traverse a UDP link > some time before reaching its final destination; i.e., the UAS may > have got the request over TCP, but there is some upstream entity > that used UDP to send the request downstream. > >> If there is a transition to UDP in the path beyond, a proxy will send 140 >> instead. This avoids duplicate 140/141 responses > > If a UAS sends a final response, there will not be any transition > in the path beyond the UAS... > I meant the upstream path, the chain formed by the Via headers. If there is one that says 'UDP', the element before that (i.e. host in Via which appears above the one with UDP) will be the one sending a 140/141 response > 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 Oct 04 03:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0lt-0002ty-Gm; Wed, 04 Oct 2006 03:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV0lr-0002tr-QV for sip@ietf.org; Wed, 04 Oct 2006 03:02:23 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV0lp-00043K-9B for sip@ietf.org; Wed, 04 Oct 2006 03:02:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k947256j009457; Wed, 4 Oct 2006 10:02:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:02:04 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 10:02:04 +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 and SigComp Date: Wed, 4 Oct 2006 10:02:02 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02CF662D@esebe103.NOE.Nokia.com> In-Reply-To: <5D1A7985295922448D5550C94DE291805159B1@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and SigComp Thread-Index: AcbmZD4S3hAOyE29QoCJMZDz3FxVRQAy5EhwABRb5QA= From: To: , , X-OriginalArrivalTime: 04 Oct 2006 07:02:04.0736 (UTC) FILETIME=[FFA44C00:01C6E782] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: rohan@ekabal.com, adam@estacado.net X-BeenThere: sip@ietf.org X-Mailman-Version: 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, >In summary therefore, I would suggest that as far as the RFCs are >currently concerned, STUN is outside of SigComp, because noone in the >STUN community has written a document to put it inside. I agree with the approach Keith proposed since in my understanding it would not make any sense to use SigComp for binary encoded STUN while according to RFC 3320 SigComp is motivated by compressing text=20 based protocols: Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size.=20 STUN messages are size-optimized and small, so you are not expected to gain much, if anything, by applying SigComp to those. However for the SIP Outbound case as both the SIP and STUN messages must share the same source and destination IP address and port, the=20 question is if multiplexing STUN messages with SigComp messages can=20 be safely done. It seems to be possible by checking the two topmost bits of the message which are always one for SigComp and zero for STUN: All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port. The most significant two bits of every STUN message are both zeroes. This, combined with the magic cookie and the fingerprint attribute, aid in differentiating STUN packets from other protocols when STUN is multiplexed with other protocols on the same port. To document this for SIP Outbound deployments using SigComp (like IMS) could a note be added to the Outbound draft about this ? Regards, Erkki >-----Original Message----- >From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]=20 >Sent: 04.October.2006 00:12 >To: Cullen Jennings; SIP; Rohan Mahy; Adam Roach >Subject: RE: [Sip] Outbound and SigComp > >RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an >application protocol. Therefore in that document there is no indication >that SigComp is designed for SIP, or for some other protocol. > >RFC 3486 (owned by SIP) specifies how SIP uses SigComp. > >On that basis, I would have thought that any group that intended their >protocol to run over SigComp would need to define how it is used in >those circumstances, as for usage over any other transport protocol.=20 > >In the absence of such a document, usage of SigComp by that protocol >would be essentially proprietary. > >In summary therefore, I would suggest that as far as the RFCs are >currently concerned, STUN is outside of SigComp, because noone in the >STUN community has written a document to put it inside. > >Views? > >Regards > >Keith > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com]=20 >> Sent: 02 October 2006 21:46 >> To: SIP; Rohan Mahy; Adam Roach >> Subject: [Sip] Outbound and SigComp >>=20 >>=20 >> A question I have been thinking about a little ... what=20 >> happens when a UA is doing both outbound and sigcomp. Is it=20 >> clear enough how this happiness? Is stun inside or outside=20 >> the sigcomp, etc? Anyways, I just wanted to lodge this as an=20 >> open issue - we probably should check that this is=20 >> reasonable clear how to do this even if we don't have to say=20 >> anything about it in outbound. >>=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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 04 07:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV55v-0003Di-BX; Wed, 04 Oct 2006 07:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV55t-00035O-NG for sip@ietf.org; Wed, 04 Oct 2006 07:39:21 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV55p-00006D-7C for sip@ietf.org; Wed, 04 Oct 2006 07:39:21 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id B38C06C01F; Wed, 4 Oct 2006 07:39:04 -0400 (EDT) Subject: Re: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Dean Willis In-Reply-To: <4522B38D.3090407@softarmor.com> References: <4522AFC5.10306@lucent.com> <4522B38D.3090407@softarmor.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 04 Oct 2006 07:39:06 -0400 Message-Id: <1159961946.2855.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 On Tue, 2006-10-03 at 14:01 -0500, Dean Willis wrote: > Vijay K. Gurbani wrote: > > Folks: An I-D on handling large UDP response has just been > > submitted to the I-D editor. Until it appears in the archives, a > > copy can be obtained from: [...] > So, are we stuck on advancing the hop-limit-diagnostics draft until we > advance something like this draft? I don't think so. This draft was, in part, inspired by the problem of how to diagnose when responses are lost due to UDP fragmentation. The hop limit responses will usually be very large (if only because of all those Via headers), so they are one of the cases. It may be that having this mechanism takes a bit of the heat off of the problem of trimming those error responses down to a size that's sure to get through, since at least some indication will... what do people think? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Oct 04 08:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5Yo-0005Xu-8P; Wed, 04 Oct 2006 08:09:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV5Yn-0005Xp-Ci for sip@ietf.org; Wed, 04 Oct 2006 08:09:13 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV5Ym-0001l2-0Z for sip@ietf.org; Wed, 04 Oct 2006 08:09:13 -0400 Received: (qmail 28192 invoked by uid 0); 4 Oct 2006 12:09:04 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Oct 2006 12:09:04 -0000 Message-ID: <00b201c6e7ad$e302fc60$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Scott Lawrence" , "Dean Willis" References: <4522AFC5.10306@lucent.com> <4522B38D.3090407@softarmor.com> <1159961946.2855.20.camel@localhost.localdomain> Subject: Re: [Sip] I-D on handling large UDP responses Date: Wed, 4 Oct 2006 14:09:04 +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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 > It may be that having this mechanism takes a bit of the heat off of the > problem of trimming those error responses down to a size that's sure to > get through, since at least some indication will... what do people > think? > Perhaps, if you would put the status line of the error response as a body in the 140/141 response. If not, the UAC would make a wrong diagnosis (and retry the request over TCP, and likely hit the same hop limit) Being a specific case, IMO splitting the hop limit response in two parts like this can help. However, generating 140/141 liberally (such as every time a transport switch occurs) concerns me. The risk is that corner cases are improved, at the cost of overall degredation of the system. 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 Oct 04 09:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV6kv-0003gs-Bx; Wed, 04 Oct 2006 09:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV6kt-0003gb-Jx for sip@ietf.org; Wed, 04 Oct 2006 09:25:47 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV6ks-00067B-6i for sip@ietf.org; Wed, 04 Oct 2006 09:25:47 -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 k94DPjlj015216; Wed, 4 Oct 2006 08:25:45 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 08:25:44 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 15:25:43 +0200 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 Date: Wed, 4 Oct 2006 15:25:42 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180515D64@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sip-acr-code-02 Thread-Index: AcbnYQYFqvRtSoD1QAKGX6xW81PVZAAV4V6A From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 04 Oct 2006 13:25:43.0178 (UTC) FILETIME=[97B3CEA0:01C6E7B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: sip@ietf.org Subject: [Sip] RE: Comments on draft-ietf-sip-acr-code-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 fixes are fine by me. Thanks Keith=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 04 October 2006 03:59 > To: Drage, Keith (Keith) > Cc: sip@ietf.org > Subject: Re: Comments on draft-ietf-sip-acr-code-02 >=20 >=20 >=20 > Drage, Keith (Keith) wrote: >=20 > > I have reviewed the entire draft. > >=20 > > 1) In section 3, I wondered if it would be appropriate to have a > > couple more key statements of when it does not apply.=20 > >=20 > > For example, if we are using RFC 4474, and the recipient of the SIP=20 > > request has received the identity but has been unable to obtain the=20 > > certificate for the identity, then the proposed 433=20 > response code is=20 > > inappropriate, and indeed RFC 4474 specifies response codes=20 > for this=20 > > situation, which should always be used in preference. >=20 > OK. I added this: >=20 > > In addition, requests where the identity of the requestor=20 > cannot be determined or validated, but it is not a=20 > consequence of an explicit action on the part of the=20 > requestor, are not consider anonymous. For example, if a=20 > request contains a non-anonymous From header field, along=20 > with the Identity and Identity-Info header fields target=3D"RFC4474"/>, but the certificate could not be obtained=20 > from the reference in the Identity-Info header field, it is=20 > not considered an anonymous request, and the 433 response=20 > code SHOULD NOT be used. > >=20 >=20 > >=20 > > 2) Section 3.=20 > >=20 > > o The request contained a Privacy header field whose=20 > value was 'id' > > [3] or 'user'. This explicitly excludes the 'header' and > > 'session' privacy services, since those do not=20 > directly convey the > > identity of the requestor. > >=20 > > I have noted the ongoing discussion on this, and certainly my > > interpretation was that the "header" value in the Privacy=20 > header could > > cover the P-Asserted-Identity header. However I think we=20 > should avoid > > that this draft attempts to fix unclear specification in=20 > RFC 3323 and > > (and possibly RFC 3325). I would therefore suggest that we=20 > strike the > > offending words. >=20 > Fine. In the interests of forward progress I will strike the=20 > offending=20 > sentence. >=20 >=20 > >=20 > > 3) Section 4. > >=20 > > This section seems to be the one that should talk about=20 > dialog usage. > > While identities are usefully provided in the initial=20 > transaction in a > > dialog, there is nothing that prevents them being exchanged in later > > transactions, and indeed for the support of some services it is > > necessary, as the identity will have changed.=20 > >=20 > > The document should indicate the effect of receiving a 433=20 > response to a > > request sent within an existing dialog, where the=20 > implementation does > > support this extension, which I assume should be the defauly 4xx > > response treatment. >=20 > I've added the following: >=20 > > Receipt of a 433 response to a mid-dialog request SHOULD NOT cause the > dialog to terminate, and SHOULD NOT cause the specific usage of that > dialog to terminate . > >=20 >=20 > Thanks, > Jonathan R. >=20 > --=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 From sip-bounces@ietf.org Wed Oct 04 10:26:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7fN-0002Ud-RZ; Wed, 04 Oct 2006 10:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7fM-0002T9-2L for sip@ietf.org; Wed, 04 Oct 2006 10:24:08 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7fH-0000DY-OL for sip@ietf.org; Wed, 04 Oct 2006 10:24:08 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 60FB96C018; Wed, 4 Oct 2006 10:23:55 -0400 (EDT) Subject: Re: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 04 Oct 2006 10:23:58 -0400 Message-Id: <1159971838.2732.20.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 On Tue, 2006-10-03 at 22:18 +0200, Jeroen van Bemmel wrote: > Three initial comments: > > 1) I would expect the main source of large responses to be the UAS sending a > large response body. A transport switch does not necessarily imply that a > large response will follow, in general I think those 140 responses will > often be a waste of bandwidth. You could instead consider sending it just > before the proxy is about to forward a response >MTU (1500 if unknown) over > UDP, and then preferrably only when no 140/141 response from some downstream > node was forwarded already (only possible to detect this for stateful > proxies). That's worth thinking about, certainly. I'd personally prefer to leave off the qualifier that makes it require a stateful proxy. The advantage of sending the 140 when sending in the downstream direction is that the proxy can be stateless and it will only send one 140 regardless of the number and size of replies coming from downstream. > 2) The current draft can result in cases where both a 140 and a 141 response > are sent, this seems wasteful. When the UAS sends a response >1500 bytes > over non-UDP, it does not necessarily imply that there will be a response > >1500 bytes using UDP at some point. So if the proxy forwarding rule is > changed per (1)above, the UAS should only send a 141 when it is sending over > UDP itself (i.e. no inspection of the via chain needed). If there is a > transition to UDP in the path beyond, a proxy will send 140 instead. This > avoids duplicate 140/141 responses The motivation for having both 140 and 141 is that it maximizes the chance that _something_ in the path will provide the hint that messages are getting large on a path without congestion control. The case we're most concerned about cutting off is the very bad one in which the real response(s) are lost, so the originator is retrying them, and if it's an INVITE the responder(s) are _also_ retrying because there's no ACK. Getting some hint to the originator that this isn't going to work offers the hope that the retries can be eliminated or forced onto a congestion controlled transport. > 3) Given the above, it could probably be done with only 1 response code. > Proxies should then set the to-tag to the to-tag of the large response Why would proxies want to behave as though they were anything other than proxies? They can leave the to-tag empty - this is a 1xx response after all. Since messages could have been reordered it doesn't matter when they send the message and the user agent has the same set of cases to deal with (that is, the UAC should not be bothered by getting a 1xx response after a final response anyway). -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Oct 04 10:36:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7oo-0002qC-LJ; Wed, 04 Oct 2006 10:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV7om-0002q4-Je for sip@ietf.org; Wed, 04 Oct 2006 10:33:52 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV7ol-0002Bl-7r for sip@ietf.org; Wed, 04 Oct 2006 10:33:52 -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 k94EXfnb027401 for ; Wed, 4 Oct 2006 09:33:46 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 09:33:42 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 16:33:41 +0200 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 Date: Wed, 4 Oct 2006 16:33:40 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180515DFF@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: draft-ietf-sip-certs-01 Thread-Index: AcbnwhXZDlFXQp6wRYGUIKttYqRTHQ== From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 04 Oct 2006 14:33:41.0112 (UTC) FILETIME=[16572780:01C6E7C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] WGLC: draft-ietf-sip-certs-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (as WG chair) This is to announce a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-01.txt Certificate Management Service for The Session Initiation Protocol (SIP) Please review and provide comments (along with any suggestions for resolution) on this document by: Thursday 19th October 2006. --------------------------- In addition, if you have reviewed and have no comments on this version of the document, that is useful (even essential) information, so please indicate this direct to the WG chairs. This document was agreed as pretty much done at IETF#66 and there have been no major comments on the list since that time. At that time there was an indication of 4 or 5 implementations - we would please ask those implementors to definitely review this version of the document and provide comments. This document was originally started in SIPPING but was transferred to SIP around the timeframe of IETF #65 primarily because it dealt with security related issues. It does however define event packages. 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 Wed Oct 04 12:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9Bk-0007ZF-Fy; Wed, 04 Oct 2006 12:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9BG-00077e-60 for sip@ietf.org; Wed, 04 Oct 2006 12:01:10 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV99Y-0003N8-VO for sip@ietf.org; Wed, 04 Oct 2006 11:59:26 -0400 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k94F2SL3018574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Oct 2006 10:02:30 -0500 In-Reply-To: <20060928061824.1zvjynhaixus4sgc@webmail.versatel.nl> References: <20060927161756.75435.qmail@web31808.mail.mud.yahoo.com> <20060928061824.1zvjynhaixus4sgc@webmail.versatel.nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C50937F-71ED-4FC8-895A-44D21265C24D@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] New Event package response code Date: Wed, 4 Oct 2006 10:59:19 -0500 To: Jeroen van Bemmel , Dan Petrie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) 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'm confused. I thought we had a rough consensus here. Somebody please hit me with a clue bat. Is the issue Jeroen identifies here a show-stopper? -- Dean On Sep 27, 2006, at 11:18 PM, jbemmel@zonnet.nl wrote: > Dan, > > The basic model in RFC3265 (and SIP/HTTP in general) is that the R- > URI contains sufficient information to identify the resource. > Adding parameters to the Event header as you propose would break > this model: the resource would be a function of the R-URI and these > parameters. So the choice is between fundamentally changing SIP or > rethinking your draft / solution > > Cleanest would perhaps be SUBSCRIBE http://xcap.example.com/root/ > resource-lists/users/joe, but the problem is that most SIP proxies > won't route such a request. The next best thing would probably be a > new URI parameter, e.g. SUBSCRIBE sip:xcap- > server.provider.com;document=http%3a//xcap.example.com/root/ > resource-lists/users/joe or an embedding in the user part, i.e. > SUBSCRIBE sip:http%3a//xcap.example.com/root/resource-lists/users/ > joe@xcap-server.provider.com > > 404 Not found would be the error response when the server does not > support this > > Regards, > > Jeroen > >> At the Montreal IETF we identified one problem with the config >> package >> usage with XCAP. XCAP is not manditory to be supported by the >> profile >> delivery server. The problem was how does the server indicate >> that it >> does not support XCAP. We agreed to use the Event header profile- >> type >> as the indication that XCAP is required (i.e. >> profile-type="application"). We also agreed that an error >> response was >> required if the server does not support XCAP. >> >> I propose that we create a new error code that extends RFC 3265. The >> error code is to indicate that an Event header has an invalid or >> unsupported value. I also propose that we create a new header field >> that contains the event header parameter(s) and unsupported values >> (s). >> >> >> E.g. Invalid-Event-Parameters: profile-type="application" >> >> I think that it is generally useful for 3265 implementation that have >> Event header parameters with enumerated values (tokens or strings). >> That is to indicate that the Event header parameter value is not >> valid >> or supported. As this is a protocol change issue, I am submitting >> this >> to the SIP list for suggestings and comments. >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 04 12:31:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9cV-0002Yg-SN; Wed, 04 Oct 2006 12:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9cU-0002YW-CG for sip@ietf.org; Wed, 04 Oct 2006 12:29:18 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9cR-00010x-UZ for sip@ietf.org; Wed, 04 Oct 2006 12:29:18 -0400 Received: (qmail 1060 invoked by uid 0); 4 Oct 2006 16:29:01 -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 < >; 4 Oct 2006 16:29:01 -0000 Message-ID: <013f01c6e7d2$3999ffa0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Scott Lawrence" References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <1159971838.2732.20.camel@sukothai.pingtel.com> Subject: Re: [Sip] I-D on handling large UDP responses Date: Wed, 4 Oct 2006 18:29:10 +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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Scott, >> 3) Given the above, it could probably be done with only 1 response code. >> Proxies should then set the to-tag to the to-tag of the large response > > Why would proxies want to behave as though they were anything other than > proxies? They can leave the to-tag empty - this is a 1xx response after > all. Since messages could have been reordered it doesn't matter when > they send the message and the user agent has the same set of cases to > deal with (that is, the UAC should not be bothered by getting a 1xx > response after a final response anyway). My thinking was that in case of forking the UAC might want to know which early dialog the problem belongs to. And for mid-dialog requests, RFC3261 8.2.6.2 says "If a request contained a To tag in the request, the To header field in the response MUST equal that of the request.". The problem with inserting a to-tag, is that the UAC will assume the response was sent by the UAS. So some dialog state based on headers such as Contact, Allow etc might get updated. You're probably right that leaving the to-tag empty is better (even for mid-dialog responses), perhaps correlation in case of forking can be solved in another way (if desired) 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 Oct 04 13:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAXa-0001ss-Lq; Wed, 04 Oct 2006 13:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVAXZ-0001qY-67 for sip@ietf.org; Wed, 04 Oct 2006 13:28:17 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVAIO-0001iM-5T for sip@ietf.org; Wed, 04 Oct 2006 13:12:40 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 9F3936C018; Wed, 4 Oct 2006 13:12:23 -0400 (EDT) Subject: Re: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Jeroen van Bemmel In-Reply-To: <013f01c6e7d2$3999ffa0$0601a8c0@BEMBUSTER> References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <1159971838.2732.20.camel@sukothai.pingtel.com> <013f01c6e7d2$3999ffa0$0601a8c0@BEMBUSTER> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 04 Oct 2006 13:12:26 -0400 Message-Id: <1159981946.2732.78.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 On Wed, 2006-10-04 at 18:29 +0200, Jeroen van Bemmel wrote: > Scott, > > >> 3) Given the above, it could probably be done with only 1 response code. > >> Proxies should then set the to-tag to the to-tag of the large response > > > > Why would proxies want to behave as though they were anything other than > > proxies? They can leave the to-tag empty - this is a 1xx response after > > all. Since messages could have been reordered it doesn't matter when > > they send the message and the user agent has the same set of cases to > > deal with (that is, the UAC should not be bothered by getting a 1xx > > response after a final response anyway). > > My thinking was that in case of forking the UAC might want to know which > early dialog the problem belongs to. And for mid-dialog requests, RFC3261 > 8.2.6.2 says "If a request contained a To tag in the request, the To header > field in the response MUST equal that of the request.". I don't think that anyone was thinking about deferred provisional responses when they wrote that... > The problem with inserting a to-tag, is that the UAC will assume the > response was sent by the UAS. So some dialog state based on headers such as > Contact, Allow etc might get updated. You're probably right that leaving the > to-tag empty is better (even for mid-dialog responses), perhaps correlation > in case of forking can be solved in another way (if desired) Well, if the UAS at the target sends the 141 then that's taken care of too. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Oct 04 14:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB9g-0005Dx-Gl; Wed, 04 Oct 2006 14:07:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVB9f-0005Dr-4j for sip@ietf.org; Wed, 04 Oct 2006 14:07:39 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVB9b-0001LV-KB for sip@ietf.org; Wed, 04 Oct 2006 14:07:39 -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 k94I7VB5027499 for ; Wed, 4 Oct 2006 13:07:31 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 13:07:31 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 20:07:29 +0200 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] GRUU WGLC comments review Date: Wed, 4 Oct 2006 20:07:28 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180563C76@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU WGLC comments review Thread-Index: AcbeKz9KWpNvs73TQjiu/v7PboRAkAJtKkkA From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 04 Oct 2006 18:07:29.0704 (UTC) FILETIME=[F4C6F280:01C6E7DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e X-BeenThere: sip@ietf.org X-Mailman-Version: 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 notes of the call we had last week are as follows. Regards Keith ------------------------------------------ Notes of conference call held on 27th September 2006 to review GRUU WGLC comments. Participating: Paul Kyzivat Robert Sparks Andrew Allen Dale Worley Jonathan Rosenberg (Editor) Dean Willis (Moderator) Eric Rescorla Keith Drage (Scribe) Review comment status as at this meeting: https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.htm=20 or https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.doc The following issues were addressed: 14) Bit about outbound proxies and what GRUU to use - comments that this is confusing. This was not a major issue, rather a need to phrase the requirements better. The list would be asked to come up with better text. 15) applicability of record-routing languages in basic trapezoid case (Cullen, tracker #112A) There are two cases here, the triangular and the trapezoid. Is there a way to turn off the record-routing in the trapezoid case. It was agreed to pull text on this issue into a standalone appendix on network design, which means that the normative text will remain very simple. 16) Alternative gruu construction algorithm from ekr (Tracker #124) EKR has already sent text to Jonathan which will be adopted. 17) SIP/SIPS text - should we say anything about SIPS? Consolidate SIPS processing? (ekr and others, tracker #49) Jonathan suggested punting text about SIPS and GRUU to a future document that would fix SIPS generally, rather than including something in GRUU that would have to change anyway. We need to consult with the Security area to see if this is OK. 18) tel URI handling (Andrew, tracker #91) Identified that RFC 3261 specifies that the address of record has to be a SIP URI. In normal use, the tel URI is an alias for the SIP URI that is the address of record. It was regarded as reasonable to add a sentence that states this, although it should be stated in terms that can be applied to all URI types and e.g. sos URN, rather than being specific to the tel URI. 19) GRUU/AOR URI equivalence - an issue? (Dale tracker #41, Francois tracker #76) Dale attempted to clarify his comment, which was that the equivalence matching rules in RFC 3261 do not apply in this case. For example when the opaque parameter is stripped then we still need to match if it has the same set of other parameters. It was agreed that we need a new URI comparison rule that is not the RFC 3261 rule in this case. 20) Escaping allowed in GRUU contact header param? (Dale, tracker #116) It was proposed that the GRUU parameter takes a quoted string and the associated text says that it is a URI. Dale would send suggested text and this issue was agreed to be resolved. 21) Do we need client generated instance ID (Aki, tracker #7) This was identified as an issue where some mechanisms already exist in ETAGS that attempt to do some of what is performed in GRUU. However the review team considered that the problems are sufficiently different to merit different solutions., e.g. softstate or not. It was considered that the proposal was insufficiently motivated to agree any change to the current mechanism. 22) Related to whether GRUU is explicit: What do UACs do differently (if anything) if a contact is a GRUU? (ekr, Dean tracker #6, others) Discussed already in previous calls on other issues. 23) Do we need more clarification on the lifetime of GRUUs?This keep coming up in non-registration-bound GRUU usages, like gateways. Can you delete a GRUU? (Robert, tracker #75) Dealt with on anonymity issue. There is one additional sublety in that we need to emphasise that a request for a new (regular) GRUU will quite likely give the same one as already in use. 24) Is the GRID functionality of UA-generated URI context something that is more generally useful than just with GRUU? (ekr) Dealt with on anonymity issue. 25) Is the GRID functionality of letting a contacted UA know that it was reached via a GRUU both needful and best done with GRID, or would another mechanism be more appropriate? (ekr) Dealt with on anonymity issue. Additionally the following two items were discussed: A) As agreed on the call last week, the gruu URI parameter will be renamed "gr". Jonathan had put a mail to the SIP WG list the previous night indicating this. B) Anonymity. It was identified that neither Cullen or Jeroen were on the call, and these were key stakeholders in this discussion. It was agreed that within the bounds of the current document, there was no need for a level of privacy that was greater than that already provided by RFC 3261. This does not preclude other documents in the future providing a mechanism for a greater level of privacy. The proposal is that on registration, two GRUUs will come back, the regular GRUU and the pseudononymous GRUU. In general UEs will need both, depending on the application they are trying to support.=20 A related question, which impacts SIPPING, was as to whether both GRUUs need to be revealed in the reg event package. It was agreed that conveyance of both would need to be supported, but that we would need to look at the text for authorization policy on the pseudononymous GRUU.=20 It was agreed that informative text was needed to indicate that the UE provides any recovery if the regular GRUU is mistakenly revealed, i.e. by blocking calls made to that GRUU. EKR agreed to produce text to make sure that the GRUU is secure and disctinct when it is minted at different times. The above was all agreed amongst the participants on the call. It was understood that there may well be people on the list who do not agree with the above and consensus will be determined on the list.=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 22 September 2006 10:41 > To: sip@ietf.org > Subject: [Sip] GRUU WGLC comments review >=20 > We will be continuing the conference calls on resolving the=20 > WGLC comments on GRUU. >=20 > Regards >=20 > Keith >=20 >=20 > > The continuation call will be on: > >=20 > > Wednesday September 27th > > ------------------------ > >=20 > > 7:00 am - 9:00 am Pacific > > 8:00 am - 10:00 am Mountain > > 9:00 am - 11:00 am Central > > 10:00 am - 12:00 midday Eastern > > 3:00 pm - 5:00 pm UK > >=20 > > Bridge details > >=20 > > Access Phone Number: 8007718734 > > International Access Phone Number: +1 6477233953 7-Digit=20 > Access Code: >=20 > > 5776249 > >=20 > > The compiled comments are at: > >=20 > > http://www.softarmor.com/sipwg/reviews/gruu/index.html > >=20 > > Other documents will also appear in this area, referenced=20 > by this same >=20 > > index page. >=20 > Keith Drage > Lucent Technologies > 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 Wed Oct 04 14:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBKq-0003J8-Hz; Wed, 04 Oct 2006 14:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBKp-0003Im-9y for sip@ietf.org; Wed, 04 Oct 2006 14:19:11 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBKk-0002uG-Fb for sip@ietf.org; Wed, 04 Oct 2006 14:19:10 -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 k94IIrj23750; Wed, 4 Oct 2006 14:18:53 -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] GRUU and Grid alternative Date: Wed, 4 Oct 2006 13:18:52 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC6D@zrc2hxm2.corp.nortel.com> In-Reply-To: <452335C4.4090305@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: AcbnbFZHLiHBWUHFRK+ynlwaP27pdgAdDRLQ From: "Brian Stucker" To: "Dean Willis" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) 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'd like to point one thing out from the annals of the way-back machine... At IETF-59 in Seoul, I made a presentation, which I recall being well received by at least a few folks (I believe Cullen was one of them) in which a separate, but related problem space to GRUU was being discussed: the GUID. The draft has expired long ago (http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-stucker-si p-guid-00.txt) but the introduction captures the problem space fairly succintly: --- Within SIP, there arise situations where it is necessary to ensure that an action is applied to a particular user agent (UA) instance,=20 but the existing mechanisms within SIP are not always reliable. For=20 example, although registrations identify a routable address and port=20 of a particular UA, in an environment that uses dynamically assigned=20 IP addresses (NATs, VPNs, short-lease DHCP networks) there is no=20 ready way of always tying registrations together across time for a particular UA instance. In these environments, the usual IP/port=20 combination that defines a particular routing location of a UA is=20 unreliable over time as an identifier of that UA.=20 As a result, an identifier that UAs can use as a "finger-printing" mechanism to identify themselves is useful. Whereas the Globally=20 Routable UA URIs (GRUU) draft [4] seeks to address a server-generated=20 identifier for the UA, this draft seeks to define a client-generated=20 approach to a similar problem.=20 The mechanism defined in this document allows a particular UA=20 instance to construct a globally unique identifier which can be used=20 by SIP services to process requests that require, or are enhanced by,=20 the ability to identify a particular UA instance in the network over=20 a long period of time.=20 --- This notion was folded into the GRUU draft as a property of the grid parameter (ie. the grid could be used as a GUID). If we're to remove the grid from gruu, I think we still want to maintain this property of the grid: it's still very useful. Regards, Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 03, 2006 11:17 PM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 > Jonathan Rosenberg wrote: >=20 > > The basic idea would be to remove the grid mechanism=20 > entirely from the=20 > > gruu draft. Instead, a separate specification would be=20 > developed which=20 > > would allow for loose routing to apply to user agents. So,=20 > consider a=20 > > UA which registers. It would include a contact and a=20 > Supported header=20 > > field with the value "ua-route". The registrar, assuming it=20 > > understands this, notes that the UA supports UA loose routing and=20 > > stores the contact. When an incoming call arrives for the=20 > AOR, rather=20 > > than rewriting the R-URI with the registered contact, it pushes the=20 > > registered contact into a Route header and leaves the R-URI alone=20 > > (assuming the registered UA supports this mechanism). >=20 > I'd like to go on record as saying that this apparently=20 > resolves one of the Great Fundamental Evils of SIP that I've=20 > so often sermonized and thereby either makes me happy and=20 > fulfilled or leaves me looking for something else to whine=20 > about. In either case, it is a very good fix, and long overdue. >=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 Oct 04 14:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBRK-0000DY-7k; Wed, 04 Oct 2006 14:25:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBRJ-0000DT-9W for sip@ietf.org; Wed, 04 Oct 2006 14:25:53 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBRH-0003sy-Ss for sip@ietf.org; Wed, 04 Oct 2006 14:25: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 k94IPll11274; Wed, 4 Oct 2006 14:25:48 -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] GRUU and Grid alternative Date: Wed, 4 Oct 2006 13:25:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> In-Reply-To: <451A10FD.8040809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: Acbh+WXA+peKsZUsQD627I7cuE9H0QF6C+vA From: "Brian Stucker" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 believe what you are describing here is essentially extending the routing mechanism used within the IMS core network to route messages between various servers (x-CSCFs, BGCFs, App Servers, etc).=20 Although this may help with a number of issues, and on the face of it is a relatively simple idea (use a separate stack data structure for routing instead of a static URI) I don't think it solves all the problems you may think it does. For instance, existing P-headers also have a trust-domain and network assertion factor associated with them. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, September 27, 2006 12:50 AM > To: IETF SIP List > Subject: [Sip] GRUU and Grid alternative >=20 > During our call on GRUU last week, there was a discussion on=20 > this issue that ekr raised, where he would like to see the=20 > grid usable outside of just gruu, i.e., with any AOR. >=20 > During the call, I made a suggestion for an alternative=20 > solution, and there was agreement amongst those on the call=20 > for the proposed approach. >=20 > The basic idea would be to remove the grid mechanism entirely=20 > from the gruu draft. Instead, a separate specification would=20 > be developed which would allow for loose routing to apply to=20 > user agents. So, consider a UA which registers. It would=20 > include a contact and a Supported header field with the value=20 > "ua-route". The registrar, assuming it understands this,=20 > notes that the UA supports UA loose routing and stores the=20 > contact. When an incoming call arrives for the AOR, rather=20 > than rewriting the R-URI with the registered contact, it=20 > pushes the registered contact into a Route header and leaves=20 > the R-URI alone (assuming the registered UA supports this mechanism). >=20 > How does this solve the grid problem? Lets say my AOR is=20 > sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some=20 > arbitrary parameter, say sip:jdrosen@cisco.com;foo=3Dbaz, and=20 > hand it out to some correspondent. When a correspondent sends=20 > a request to that URI, it arrives at my home proxy. From=20 > there, since the R-URI is NOT rewritten, the entire URI,=20 > parameters and all, is passed to the UA. Thus, the UA knows=20 > the URI that was de-referenced. We wouldn't necessarily have=20 > to standardize a specific URI parameter, like grid, to carry=20 > the opaque data. >=20 > This trick solves a whole bunch of other problems too. It=20 > would eliminate the need for the IMS P-Called-Party-ID header=20 > field, and it would help clarify when a request is retargeted=20 > (change in R-URI) vs.=20 > when its just being delivered to the recipient (no change in R-URI). >=20 > Comments? >=20 > -Jonathan R. >=20 >=20 > --=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=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 Oct 04 14:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBWI-0006JH-Vj; Wed, 04 Oct 2006 14:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBWH-0006In-Td for sip@ietf.org; Wed, 04 Oct 2006 14:31:01 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBWG-0004dR-FZ for sip@ietf.org; Wed, 04 Oct 2006 14:31:01 -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 k94IUkt14272; Wed, 4 Oct 2006 14:30:47 -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] GRUU and Grid alternative Date: Wed, 4 Oct 2006 13:30:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CCB9@zrc2hxm2.corp.nortel.com> In-Reply-To: <451B3906.1000903@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: AcbiqeRl1AiNy5DMToeBEc2tCU2fSgFOL2Ng From: "Brian Stucker" To: "Jonathan Rosenberg" , 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 Maybe I'm missing something here, but aren't the proxies between the UAC and the proxy that would normally rewrite the request-URI for delivery of the request to the final UAS still going to be rewriting the request URI (potentially) along the way? Doesn't that mean that the UAS doesn't know what the original URI the UAC specified was? It only knows the URI that existed just before the proxy that handled routing to the UAS's registered contacts was. ??? Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, September 27, 2006 9:53 PM > To: jbemmel@zonnet.nl > Cc: IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 >=20 >=20 > jbemmel@zonnet.nl wrote: >=20 > > Jonathan, > >=20 > > Yes, I think this would work as a cleaner / more general=20 > solution than=20 > > grid > >=20 > > For the mechanism, the UA would need to insert a 'lr'=20 > parameter into=20 > > its Contact. This is needed for Path proxy traversal, and makes the=20 > > logic at the registrar simpler (i.e. if registered contact URI=20 > > contains a lr then append Route, else rewrite) > >=20 > > Perhaps 'lr' alone could be sufficient (i.e. no Supported) although=20 > > you may want an option tag to detect support for this feature >=20 > Indeed. This was going to be my next post. >=20 > One of the problems with using Supported/Require in REGISTER,=20 > is that it only works for proxy translation services based on=20 > registrations. Other services, such as routing to a PSTN=20 > gateway, or application routing, are not populated by a=20 > registration. So, how would a proxy know whether to rewrite=20 > the R-URI or push a Route? >=20 > The idea, as you suggest, is that if the target URI has a ;lr=20 > parameter, the proxy would push a Route. Otherwise, it=20 > rewrites the request uri. In this case, when a UA registers,=20 > rather than using Supported/Require, it could just place a=20 > URI into the Contact which contains the ;lr parameter. >=20 > This works just fine as long as you assume that existing UA=20 > and routing table configurations are NOT using the ;lr=20 > parameter. I got some reports that existing UA were=20 > populating the Contact header field with URIs with the ;lr=20 > parameter, just because they "support" loose routing (RFC 3261).=20 > This behavior would break the idea of using the ;lr flag to=20 > indicate this feature. >=20 > A hybrid is to use the ;lr flag just for non-register based=20 > location services, and then use Supported/Require for registrations. >=20 >=20 > >=20 > > One difference with request URI rewriting is that the latter is=20 > > automatically a one-time operation: once the URI is=20 > rewritten, the proxy=20 > > won't rewrite again when the request spirals. For Route=20 > this is not the=20 > > case. OTOH, if there are any Route headers the proxy shouldn't be=20 > > rewriting / adding a route in the first place, >=20 > No. Consider the case of a Path headers. In this case, the home proxy=20 > would populate the Route headers from the path set, and then=20 > push the UA=20 > route as the *last* Route header field. But anyway I don't understand=20 > the issue you are raising with spiraling. On each spiral, a new Route=20 > gets pushed. If instead you had R-URI rewriting, the only way the=20 > request would get back to the proxy is if the r-uri pointed to that=20 > proxy, and upon arriving there it would be rewritten again.=20 > So there is=20 > no difference. >=20 > -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 Wed Oct 04 14:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBaE-0007yE-Bh; Wed, 04 Oct 2006 14:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBaC-0007w9-T5 for sip@ietf.org; Wed, 04 Oct 2006 14:35:04 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBa9-0005Rk-JP for sip@ietf.org; Wed, 04 Oct 2006 14:35:04 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 04 Oct 2006 11:35:01 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="1856497052:sNHT47806308" 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 k94IZ1Xh000771; Wed, 4 Oct 2006 11:35:01 -0700 Received: from [10.242.56.111] (sjc-vpn1-486.cisco.com [10.21.97.230]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k94IYuif006536; Wed, 4 Oct 2006 11:35:00 -0700 (PDT) In-Reply-To: <50B1CBA96870A34799A506B2313F266709EBBBE9@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266709EBBBE9@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27A30269-DD88-4B0D-A1C2-703B09344451@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] RE: draft-ietf-sip-connected-identity-01 comments Date: Wed, 4 Oct 2006 11:05:59 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=982; t=1159986901; x=1160850901; 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]=20RE=3A=20draft-ietf-sip-connected-identity-01=20comments; X=v=3Dcisco.com=3B=20h=3DcrCanimBPejkFCrZi1O5sx3pSq0=3D; b=zMHAkYO8IwvlPWeeuhhXq5+GHN7lFFZzX+4W62hBzwZW7IARndRSqwqK8TdFul/9IamFAPxa AlOETwgU4ETb52ymKmBM2yIJcoYSRK3WipIRdHyV0+4P9VXtEvaPFglK; 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: d6b246023072368de71562c0ab503126 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 Sep 22, 2006, at 3:29 AM, Elwell, John wrote: >> The name of the option tag "id-change" sort of bugs me. What is >> allowed to change here does not really have to do with identity as >> much as the from URI. I would prefer the name "from-change" as what >> this is saying is only that part of 2543 was not required by the UA. > [JRE] Well, the URI is the identity, so I don't really understand your > point. It was changed to "id-change" from something rather longer a > draft or > so back, so I would be reluctant to change it again. Any other > opinions? At the high level I have no real objection to whatever we call this - it's just some bits on the wire and I would not hold the draft up over any name of it. On the lower level, the from URI is just one of the identities floating around, we have AIB, S/MIME signers, PAI, the list goes on. Anyways, I'll go with whatever folks decide - this one truly is in the category of rearranging deck chairs :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 04 14:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBa8-0007qc-EO; Wed, 04 Oct 2006 14:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBa7-0007qS-AK for sip@ietf.org; Wed, 04 Oct 2006 14:34:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBa6-0005RF-13 for sip@ietf.org; Wed, 04 Oct 2006 14:34:59 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2006 11:34:58 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="328096750:sNHT52185244" 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 k94IYv9w003217; Wed, 4 Oct 2006 11:34:57 -0700 Received: from [10.242.56.111] (sjc-vpn1-486.cisco.com [10.21.97.230]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k94IYuid006536; Wed, 4 Oct 2006 11:34:56 -0700 (PDT) In-Reply-To: <450EA5D9.1060305@cisco.com> References: <285E7350-8C4F-4A92-8E1E-3BFAC67CC8EC@cisco.com> <4505B74C.90506@cisco.com> <450B1025.6010305@cisco.com> <6BC8C183-DAAF-4763-82CD-AF405AC6823D@cisco.com> <450EA5D9.1060305@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B025982-DEA0-46D2-B850-8B6DB15BB7B2@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-ietf-sip-gruu-10 comments Date: Wed, 4 Oct 2006 10:58:45 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1205; t=1159986897; x=1160850897; 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-gruu-10=20comments; X=v=3Dcisco.com=3B=20h=3DWfCaFaeXb1Q2ofWJ9m44BX0SOYo=3D; b=h5WitQ8tudXwSnJ36wy/D9ZWoojkvCP/wVPAqw1B8YhxC8cpYnWXD/RFqxi6qnUWNdQXJCFV Sp/14k+v1o1HxOFqhanGJLaOOucm0WGvK8thkb2Qivj7NJatf9FTPgfF; 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: 2409bba43e9c8d580670fda8b695204a Cc: SIP , 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 sorry for slow reply --- inline On Sep 18, 2006, at 6:57 AM, Jonathan Rosenberg wrote: > My view on this is that, with GRUU, the home proxy in the > terminating domain is going to get visited ANYWAY, even with just a > trapezoid. So there is no penalty to record-routing, besides > perhaps the overhead in the sip message for the extra bytes. Thus > it seems simpler to say that you should always do it. well the domain that the GRUU points at is going to get visited - the issue is that this forces that home domain to also get visited and though they are often the same thing I can easily imagine cases where they are not - particularly when the GRUU was not generated by the a REGISTER message. > > It is a fair point that in mixed mode deployments where not all > endpoints in a domain support gruu, the record-route would not be > needed and would introduce an extra hop. I think it would be OK to > say that if the registered contact was assigned a gruu, then the > home proxy has to record-route. Would that be OK? I don't even know what I want here so I suspect I am fine with this as long as you have some of these use cases in mind too. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 04 14:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBaX-0000QL-OS; Wed, 04 Oct 2006 14:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBaW-0000Mq-9M for sip@ietf.org; Wed, 04 Oct 2006 14:35:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBaT-0005Tc-AA for sip@ietf.org; Wed, 04 Oct 2006 14:35:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Oct 2006 11:35:17 -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 k94IZHEn007176; Wed, 4 Oct 2006 11:35:17 -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 k94IZHJn006522; Wed, 4 Oct 2006 11:35:17 -0700 (PDT) Received: from [171.71.97.102] (dhcp-171-71-97-102.cisco.com [171.71.97.102]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k94IO8ex024782; Wed, 4 Oct 2006 11:24:08 -0700 Message-ID: <4523FEEF.1080501@cisco.com> Date: Wed, 04 Oct 2006 11:35:27 -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: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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=2911; t=1159986917; x=1160850917; 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:Re=3A=20[Sip]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DVcADUG4YAjhJCOUESy9WKP9y43s=3D; b=Ukvpce9S7B/dc8Na1c59PenuMfuOpF+nVngJKtU6tnE1JUGVetMXrG7gx3R6RejSW0YO0/Xi KFXlPqLaaEAlHYws9dWrVgfC62JEoPWIbTu67Fn0ZYdO/502KfWDbMG8; X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: SIP , Pete Cordell , Robert Sparks , 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 Cullen Jennings wrote: > > On Oct 3, 2006, at 12:52 PM, Robert Sparks wrote: > >> >> I take it you are explicitly objecting to the statement that MD5 is >> a reasonable non-normatively specified choice? >> You have also clearly objected to 128 as a suggestion (The text does >> NOT mandate a length). >> >> RjS > > > Yes - MD5 is a cryptographic hash and I thought we all agreed that > use off cryptographic hash was not the best choice. If we think > cryptographic hash ideas are a good idea, then we need to explain why. > > Using a cryptographic hash, even in an example, is a huge red flag > for any security person reviewing this. The fact that we used this > particular one which has significant security issues, is a even > bigger issue. Uh, no. These aren't even remotely comparable. I'm going to make a big leap here and guess that people aren't trying to actively _attack_ these forking hashes. _That's_ the problem with MD5 with security. If you're just using it as a _hashing_ algorithm that has a low probability of collisions, it's just fine. That is: unless you're going to say that the forking hash needs to be resisitant to collisions from an attacker's chosen text to do something nefarious, the problems with MD5 (or SHA1) don't apply. > Partially I think MD5 is totally lame to use here because it is slow > and offer no advantages over better things and partially I am trying > to avoid any delays due to security review where someone points out > we should not be using MD5 in new protocols. The only knock in my mind is that it may be slower than something else, but I'd worry a great deal about the "something else" if collisions are a problem. Just randomly inventing a good hashing algorithm with good collision properties especially with similar chosen text is not exactly the easiest thing to do. Since you're relying on this for carrying state, I think it's a bad idea to not at least do a SHOULD level algorithm(s) and be very certain that the algorithm you choose actual has the collision resistance needed. I'm not an expert here by any means, but my recollection is that CRC does NOT have very good properties that way. Mike > If the we can't figure out a reasonable hash to suggest, how should > an implementer figure out what to use. I've been trying to say, I > don't care what but don't choose a cryptographic one. If people have > a good reason for wanting MD5, I'm glad to listen but I just had not > heard the reason yet. > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 04 14:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBfC-0005YZ-Dk; Wed, 04 Oct 2006 14:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBfB-0005XE-AU for sip@ietf.org; Wed, 04 Oct 2006 14:40:13 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBf9-0006DF-Pd for sip@ietf.org; Wed, 04 Oct 2006 14:40:13 -0400 Received: (qmail 17826 invoked by uid 0); 4 Oct 2006 18:39:56 -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 < >; 4 Oct 2006 18:39:56 -0000 Message-ID: <019e01c6e7e4$836f5870$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Brian Stucker" , "Jonathan Rosenberg" References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CCB9@zrc2hxm2.corp.nortel.com> Subject: Re: [Sip] GRUU and Grid alternative Date: Wed, 4 Oct 2006 20:40:06 +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.2962 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 Brian, If the original requester used a GRUU as request URI, none but the proxy responsible for the corresponding domain is allowed to rewrite it. It is possible there was some other URI that got rewritten into a GRUU (eg through a 3rd party registration using a GRUU as Contact), but then still what arrives at the home proxy has a GRUU in the request URI. Regards, Jeroen ----- Original Message ----- From: "Brian Stucker" To: "Jonathan Rosenberg" ; Cc: "IETF SIP List" Sent: Wednesday, October 04, 2006 8:30 PM Subject: RE: [Sip] GRUU and Grid alternative Maybe I'm missing something here, but aren't the proxies between the UAC and the proxy that would normally rewrite the request-URI for delivery of the request to the final UAS still going to be rewriting the request URI (potentially) along the way? Doesn't that mean that the UAS doesn't know what the original URI the UAC specified was? It only knows the URI that existed just before the proxy that handled routing to the UAS's registered contacts was. ??? Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, September 27, 2006 9:53 PM > To: jbemmel@zonnet.nl > Cc: IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative > > > > jbemmel@zonnet.nl wrote: > > > Jonathan, > > > > Yes, I think this would work as a cleaner / more general > solution than > > grid > > > > For the mechanism, the UA would need to insert a 'lr' > parameter into > > its Contact. This is needed for Path proxy traversal, and makes the > > logic at the registrar simpler (i.e. if registered contact URI > > contains a lr then append Route, else rewrite) > > > > Perhaps 'lr' alone could be sufficient (i.e. no Supported) although > > you may want an option tag to detect support for this feature > > Indeed. This was going to be my next post. > > One of the problems with using Supported/Require in REGISTER, > is that it only works for proxy translation services based on > registrations. Other services, such as routing to a PSTN > gateway, or application routing, are not populated by a > registration. So, how would a proxy know whether to rewrite > the R-URI or push a Route? > > The idea, as you suggest, is that if the target URI has a ;lr > parameter, the proxy would push a Route. Otherwise, it > rewrites the request uri. In this case, when a UA registers, > rather than using Supported/Require, it could just place a > URI into the Contact which contains the ;lr parameter. > > This works just fine as long as you assume that existing UA > and routing table configurations are NOT using the ;lr > parameter. I got some reports that existing UA were > populating the Contact header field with URIs with the ;lr > parameter, just because they "support" loose routing (RFC 3261). > This behavior would break the idea of using the ;lr flag to > indicate this feature. > > A hybrid is to use the ;lr flag just for non-register based > location services, and then use Supported/Require for registrations. > > > > > > One difference with request URI rewriting is that the latter is > > automatically a one-time operation: once the URI is > rewritten, the proxy > > won't rewrite again when the request spirals. For Route > this is not the > > case. OTOH, if there are any Route headers the proxy shouldn't be > > rewriting / adding a route in the first place, > > No. Consider the case of a Path headers. In this case, the home proxy > would populate the Route headers from the path set, and then > push the UA > route as the *last* Route header field. But anyway I don't understand > the issue you are raising with spiraling. On each spiral, a new Route > gets pushed. If instead you had R-URI rewriting, the only way the > request would get back to the proxy is if the r-uri pointed to that > proxy, and upon arriving there it would be rewritten again. > So there is > no difference. > > -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 Wed Oct 04 15:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBww-0001lu-88; Wed, 04 Oct 2006 14:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBwu-0001Mj-Ft for sip@ietf.org; Wed, 04 Oct 2006 14:58:32 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBkW-0006jh-3G for sip@ietf.org; Wed, 04 Oct 2006 14:45:46 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k94Ijcjm006245; Wed, 4 Oct 2006 13:45:38 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 13:45:38 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Oct 2006 20:45:37 +0200 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 on handling large UDP responses Date: Wed, 4 Oct 2006 20:45:35 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180563C7D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbnbnypi7VqhST5TKezBcPeK4v/tQAdqWTw From: "Drage, Keith \(Keith\)" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 04 Oct 2006 18:45:37.0011 (UTC) FILETIME=[481E4C30:01C6E7E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Can you tell us what you agreed on. The proceedings seem to have missed it, and I don't remember it appearing on the list. Regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 04 October 2006 05:32 > To: Dean Willis > Cc: IETF SIP List; Vijay K. Gurbani > Subject: Re: [Sip] I-D on handling large UDP responses >=20 >=20 > On Oct 3, 2006, at 12:01 PM, Dean Willis wrote: >=20 > > So, are we stuck on advancing the hop-limit-diagnostics=20 > draft until we=20 > > advance something like this draft? >=20 > At the last IETF, I think Vijay, Scott and I had come up with=20 > a way to deal with hop-limit-diag without doing this but I=20 > have no objections if folks want to have it wait for=20 > something like this. >=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 Oct 04 15:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCJ2-00019i-QR; Wed, 04 Oct 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 1GVCJ1-00018A-9w for sip@ietf.org; Wed, 04 Oct 2006 15:21:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCIz-0004hd-QG for sip@ietf.org; Wed, 04 Oct 2006 15:21:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2006 15:21:22 -0400 X-IronPort-AV: i="4.09,256,1157342400"; d="scan'208"; a="105732206:sNHT60727708" 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 k94JLLlR026473; Wed, 4 Oct 2006 15:21:21 -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 k94JLLdM015895; Wed, 4 Oct 2006 15:21:21 -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, 4 Oct 2006 15:21:21 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:21:20 -0400 Message-ID: <452409B1.3030505@cisco.com> Date: Wed, 04 Oct 2006 15:21:21 -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: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CCB9@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CCB9@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:21:20.0781 (UTC) FILETIME=[45E7A3D0:01C6E7EA] DKIM-Signature: a=rsa-sha1; q=dns; l=5004; t=1159989681; x=1160853681; 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]=20GRUU=20and=20Grid=20alternative |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=dJqPVhyKYP0qHRwBmwvdmFCGa4LaJ8Ww9wr20snUz++fEXoykRNnoL7IGaZ27BAr48YDU+y0 t4wTfyCFyIuikOJ19OfjL2uQZ9AeYPfsxiIZfFWUoJRk9abfIfbBo1Qc; 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: dbb8771284c7a36189745aa720dc20ab 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 They're not supposed to; you're only supposed to rewrite the r-uri if you own the domain there. For mid-dialog requests TODAY that would be the contact of the UAS, which is an IP address or hostname of the client and thus not rewritable by anyone but the UAS. With gruu it would be the owner of the domain, same as the home proxy. Do you have a use case where a proxy prior to the home proxy does this? -Jonathan R. Brian Stucker wrote: > Maybe I'm missing something here, but aren't the proxies between the UAC > and the proxy that would normally rewrite the request-URI for delivery > of the request to the final UAS still going to be rewriting the request > URI (potentially) along the way? > > Doesn't that mean that the UAS doesn't know what the original URI the > UAC specified was? It only knows the URI that existed just before the > proxy that handled routing to the UAS's registered contacts was. > > ??? > > Regards, > Brian > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Wednesday, September 27, 2006 9:53 PM >>To: jbemmel@zonnet.nl >>Cc: IETF SIP List >>Subject: Re: [Sip] GRUU and Grid alternative >> >> >> >>jbemmel@zonnet.nl wrote: >> >> >>>Jonathan, >>> >>>Yes, I think this would work as a cleaner / more general >> >>solution than >> >>>grid >>> >>>For the mechanism, the UA would need to insert a 'lr' >> >>parameter into >> >>>its Contact. This is needed for Path proxy traversal, and makes the >>>logic at the registrar simpler (i.e. if registered contact URI >>>contains a lr then append Route, else rewrite) >>> >>>Perhaps 'lr' alone could be sufficient (i.e. no Supported) although >>>you may want an option tag to detect support for this feature >> >>Indeed. This was going to be my next post. >> >>One of the problems with using Supported/Require in REGISTER, >>is that it only works for proxy translation services based on >>registrations. Other services, such as routing to a PSTN >>gateway, or application routing, are not populated by a >>registration. So, how would a proxy know whether to rewrite >>the R-URI or push a Route? >> >>The idea, as you suggest, is that if the target URI has a ;lr >>parameter, the proxy would push a Route. Otherwise, it >>rewrites the request uri. In this case, when a UA registers, >>rather than using Supported/Require, it could just place a >>URI into the Contact which contains the ;lr parameter. >> >>This works just fine as long as you assume that existing UA >>and routing table configurations are NOT using the ;lr >>parameter. I got some reports that existing UA were >>populating the Contact header field with URIs with the ;lr >>parameter, just because they "support" loose routing (RFC 3261). >>This behavior would break the idea of using the ;lr flag to >>indicate this feature. >> >>A hybrid is to use the ;lr flag just for non-register based >>location services, and then use Supported/Require for registrations. >> >> >> >>>One difference with request URI rewriting is that the latter is >>>automatically a one-time operation: once the URI is >> >>rewritten, the proxy >> >>>won't rewrite again when the request spirals. For Route >> >>this is not the >> >>>case. OTOH, if there are any Route headers the proxy shouldn't be >>>rewriting / adding a route in the first place, >> >>No. Consider the case of a Path headers. In this case, the home proxy >>would populate the Route headers from the path set, and then >>push the UA >>route as the *last* Route header field. But anyway I don't understand >>the issue you are raising with spiraling. On each spiral, a new Route >>gets pushed. If instead you had R-URI rewriting, the only way the >>request would get back to the proxy is if the r-uri pointed to that >>proxy, and upon arriving there it would be rewritten again. >>So there is >>no difference. >> >>-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 Wed Oct 04 15:24:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCKb-0001qy-0Y; Wed, 04 Oct 2006 15:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCKZ-0001qm-Hk for sip@ietf.org; Wed, 04 Oct 2006 15:22:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCKW-0004up-3R for sip@ietf.org; Wed, 04 Oct 2006 15:22:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2006 12:22:56 -0700 X-IronPort-AV: i="4.09,256,1157353200"; d="scan'208"; a="44850956:sNHT59943750" 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 k94JMtrD027349; Wed, 4 Oct 2006 15:22:55 -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 k94JMtdM016742; Wed, 4 Oct 2006 15:22:55 -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, 4 Oct 2006 15:22:55 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:22:54 -0400 Message-ID: <45240A0F.8@cisco.com> Date: Wed, 04 Oct 2006 15:22:55 -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: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC6D@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC6D@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:22:54.0947 (UTC) FILETIME=[7E083B30:01C6E7EA] DKIM-Signature: a=rsa-sha1; q=dns; l=4512; t=1159989775; x=1160853775; 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]=20GRUU=20and=20Grid=20alternative |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=Duidua6Ru8iMlo4RpU6Jc+yQKZ3xU/KoZ5rzc/ebjDDL4fGLja69IWkJN+BavNJo/49Kq8Rn 3ECANUG4IGb29djCGYq5oYNxNVKUdarkYNH3x9O4qOY5rpiB+THwbYTJ; 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: b2809b6f39decc6de467dcf252f42af1 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 I'm lost on what this has to do with grid... isnt the instance ID the client generated identifier? -Jonathan R. Brian Stucker wrote: > I'd like to point one thing out from the annals of the way-back > machine... > > At IETF-59 in Seoul, I made a presentation, which I recall being well > received by at least a few folks (I believe Cullen was one of them) in > which a separate, but related problem space to GRUU was being discussed: > the GUID. > > The draft has expired long ago > (http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-stucker-si > p-guid-00.txt) but the introduction captures the problem space fairly > succintly: > > --- > Within SIP, there arise situations where it is necessary to ensure > > that an action is applied to a particular user agent (UA) > instance, > but the existing mechanisms within SIP are not always reliable. > For > example, although registrations identify a routable address and > port > of a particular UA, in an environment that uses dynamically > assigned > IP addresses (NATs, VPNs, short-lease DHCP networks) there is no > ready way of always tying registrations together across time for a > > particular UA instance. In these environments, the usual IP/port > combination that defines a particular routing location of a UA is > unreliable over time as an identifier of that UA. > > As a result, an identifier that UAs can use as a "finger-printing" > > mechanism to identify themselves is useful. Whereas the Globally > Routable UA URIs (GRUU) draft [4] seeks to address a > server-generated > identifier for the UA, this draft seeks to define a > client-generated > approach to a similar problem. > > The mechanism defined in this document allows a particular UA > instance to construct a globally unique identifier which can be > used > by SIP services to process requests that require, or are enhanced > by, > the ability to identify a particular UA instance in the network > over > a long period of time. > --- > > This notion was folded into the GRUU draft as a property of the grid > parameter (ie. the grid could be used as a GUID). > > If we're to remove the grid from gruu, I think we still want to maintain > this property of the grid: it's still very useful. > > Regards, > Brian > > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Tuesday, October 03, 2006 11:17 PM >>To: Jonathan Rosenberg >>Cc: IETF SIP List >>Subject: Re: [Sip] GRUU and Grid alternative >> >>Jonathan Rosenberg wrote: >> >> >>>The basic idea would be to remove the grid mechanism >> >>entirely from the >> >>>gruu draft. Instead, a separate specification would be >> >>developed which >> >>>would allow for loose routing to apply to user agents. So, >> >>consider a >> >>>UA which registers. It would include a contact and a >> >>Supported header >> >>>field with the value "ua-route". The registrar, assuming it >>>understands this, notes that the UA supports UA loose routing and >>>stores the contact. When an incoming call arrives for the >> >>AOR, rather >> >>>than rewriting the R-URI with the registered contact, it pushes the >>>registered contact into a Route header and leaves the R-URI alone >>>(assuming the registered UA supports this mechanism). >> >>I'd like to go on record as saying that this apparently >>resolves one of the Great Fundamental Evils of SIP that I've >>so often sermonized and thereby either makes me happy and >>fulfilled or leaves me looking for something else to whine >>about. In either case, it is a very good fix, and long overdue. >> >>-- >>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 >> > > -- 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 Oct 04 15:26:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCLm-0003OB-KW; Wed, 04 Oct 2006 15:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVCLl-0003Ih-5J for sip@ietf.org; Wed, 04 Oct 2006 15:24:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVCLj-00053Z-P7 for sip@ietf.org; Wed, 04 Oct 2006 15:24:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2006 15:24:12 -0400 X-IronPort-AV: i="4.09,256,1157342400"; d="scan'208"; a="105732570:sNHT57940896" 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 k94JOBRS027964; Wed, 4 Oct 2006 15:24:11 -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 k94JOBuI009037; Wed, 4 Oct 2006 15:24:11 -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, 4 Oct 2006 15:24:11 -0400 Received: from [161.44.55.134] ([161.44.55.134]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 15:24:11 -0400 Message-ID: <45240A5B.3000103@cisco.com> Date: Wed, 04 Oct 2006 15:24: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: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2006 19:24:11.0034 (UTC) FILETIME=[AB622FA0:01C6E7EA] DKIM-Signature: a=rsa-sha1; q=dns; l=4199; t=1159989851; x=1160853851; 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]=20GRUU=20and=20Grid=20alternative |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=LhbiYT2SeVjwJxcXfLgdx/Uwtx0FqllwB9tjTXNZfRmYLfyUIuCE1e1YUxrvd+kmBGSVhxtg BzqjLOsSoMG+gEMxsp2mEy1Kf0OU52pky+0OTZNlOQHfAoRsfo8xCBzU; 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: 6e922792024732fb1bb6f346e63517e4 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 follow. The only P-header issue this solves is P-Called-Party-ID. That header was added to deal exactly with this issue of the r-uri being rewritten, so the UAS doesn't know which public identity was targeted by the request. By not rewriting the request URI that problem is eliminated. What trust-domain issues are you referring to? -Jonathan R. Brian Stucker wrote: > I believe what you are describing here is essentially extending the > routing mechanism used within the IMS core network to route messages > between various servers (x-CSCFs, BGCFs, App Servers, etc). > > Although this may help with a number of issues, and on the face of it is > a relatively simple idea (use a separate stack data structure for > routing instead of a static URI) I don't think it solves all the > problems you may think it does. > > For instance, existing P-headers also have a trust-domain and network > assertion factor associated with them. > > Regards, > Brian > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Wednesday, September 27, 2006 12:50 AM >>To: IETF SIP List >>Subject: [Sip] GRUU and Grid alternative >> >>During our call on GRUU last week, there was a discussion on >>this issue that ekr raised, where he would like to see the >>grid usable outside of just gruu, i.e., with any AOR. >> >>During the call, I made a suggestion for an alternative >>solution, and there was agreement amongst those on the call >>for the proposed approach. >> >>The basic idea would be to remove the grid mechanism entirely >>from the gruu draft. Instead, a separate specification would >>be developed which would allow for loose routing to apply to >>user agents. So, consider a UA which registers. It would >>include a contact and a Supported header field with the value >>"ua-route". The registrar, assuming it understands this, >>notes that the UA supports UA loose routing and stores the >>contact. When an incoming call arrives for the AOR, rather >>than rewriting the R-URI with the registered contact, it >>pushes the registered contact into a Route header and leaves >>the R-URI alone (assuming the registered UA supports this mechanism). >> >>How does this solve the grid problem? Lets say my AOR is >>sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some >>arbitrary parameter, say sip:jdrosen@cisco.com;foo=baz, and >>hand it out to some correspondent. When a correspondent sends >>a request to that URI, it arrives at my home proxy. From >>there, since the R-URI is NOT rewritten, the entire URI, >>parameters and all, is passed to the UA. Thus, the UA knows >>the URI that was de-referenced. We wouldn't necessarily have >>to standardize a specific URI parameter, like grid, to carry >>the opaque data. >> >>This trick solves a whole bunch of other problems too. It >>would eliminate the need for the IMS P-Called-Party-ID header >>field, and it would help clarify when a request is retargeted >>(change in R-URI) vs. >>when its just being delivered to the recipient (no change in R-URI). >> >>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 Wed Oct 04 16:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDE0-0005Dh-8x; Wed, 04 Oct 2006 16:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDDy-00058M-8y for sip@ietf.org; Wed, 04 Oct 2006 16:20:14 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDDv-0006YX-QG for sip@ietf.org; Wed, 04 Oct 2006 16:20: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 k94KK7l29170; Wed, 4 Oct 2006 16:20:07 -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] GRUU and Grid alternative Date: Wed, 4 Oct 2006 15:19:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> In-Reply-To: <452409B1.3030505@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: Acbn6kqRqy6+hGdeSmiZ9gqQ/cUsqgABs6Zw From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 agree that proxies that don't own the targeted domain should leave the R-URI alone (although I wouldn't bet against there being proxies out there that tack junk onto the R-URI even though they don't own it, I don't think we should address this case). Yeah, I think this can happen in cases where there may be multiple routing steps involved in resolving the called party for a given domain. I think you're limiting the behavior of the home proxy to a single R-URI encoding step in resolving the final request URI, or, further, there being only one proxy that handles "home" requests for the UAS. For instance the UAC may have specified an alternative address for the UAS in the request URI, and a routing function in the middle normalized the request URI to a preferred value. As a result, the UAC's original R-URI may be lost. I think this would be a valid usecase. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, October 04, 2006 2:21 PM > To: Stucker, Brian (RICH1:AR00) > Cc: jbemmel@zonnet.nl; IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 > They're not supposed to; you're only supposed to rewrite the=20 > r-uri if you own the domain there. For mid-dialog requests=20 > TODAY that would be the contact of the UAS, which is an IP=20 > address or hostname of the client and thus not rewritable by=20 > anyone but the UAS. With gruu it would be the owner of the=20 > domain, same as the home proxy. >=20 > Do you have a use case where a proxy prior to the home proxy=20 > does this? >=20 > -Jonathan R. >=20 > Brian Stucker wrote: >=20 > > Maybe I'm missing something here, but aren't the proxies=20 > between the=20 > > UAC and the proxy that would normally rewrite the request-URI for=20 > > delivery of the request to the final UAS still going to be=20 > rewriting=20 > > the request URI (potentially) along the way? > >=20 > > Doesn't that mean that the UAS doesn't know what the=20 > original URI the=20 > > UAC specified was? It only knows the URI that existed just=20 > before the=20 > > proxy that handled routing to the UAS's registered contacts was. > >=20 > > ??? > >=20 > > Regards, > > Brian > >=20 > >=20 > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: Wednesday, September 27, 2006 9:53 PM > >>To: jbemmel@zonnet.nl > >>Cc: IETF SIP List > >>Subject: Re: [Sip] GRUU and Grid alternative > >> > >> > >> > >>jbemmel@zonnet.nl wrote: > >> > >> > >>>Jonathan, > >>> > >>>Yes, I think this would work as a cleaner / more general > >> > >>solution than > >> > >>>grid > >>> > >>>For the mechanism, the UA would need to insert a 'lr'=20 > >> > >>parameter into > >> > >>>its Contact. This is needed for Path proxy traversal, and=20 > makes the=20 > >>>logic at the registrar simpler (i.e. if registered contact URI=20 > >>>contains a lr then append Route, else rewrite) > >>> > >>>Perhaps 'lr' alone could be sufficient (i.e. no Supported)=20 > although=20 > >>>you may want an option tag to detect support for this feature > >> > >>Indeed. This was going to be my next post. > >> > >>One of the problems with using Supported/Require in=20 > REGISTER, is that=20 > >>it only works for proxy translation services based on=20 > registrations.=20 > >>Other services, such as routing to a PSTN gateway, or application=20 > >>routing, are not populated by a registration. So, how would a proxy=20 > >>know whether to rewrite the R-URI or push a Route? > >> > >>The idea, as you suggest, is that if the target URI has a ;lr=20 > >>parameter, the proxy would push a Route. Otherwise, it rewrites the=20 > >>request uri. In this case, when a UA registers, rather than using=20 > >>Supported/Require, it could just place a URI into the Contact which=20 > >>contains the ;lr parameter. > >> > >>This works just fine as long as you assume that existing UA and=20 > >>routing table configurations are NOT using the ;lr parameter. I got=20 > >>some reports that existing UA were populating the Contact=20 > header field=20 > >>with URIs with the ;lr parameter, just because they "support" loose=20 > >>routing (RFC 3261). > >>This behavior would break the idea of using the ;lr flag to=20 > indicate=20 > >>this feature. > >> > >>A hybrid is to use the ;lr flag just for non-register based=20 > location=20 > >>services, and then use Supported/Require for registrations. > >> > >> > >> > >>>One difference with request URI rewriting is that the latter is=20 > >>>automatically a one-time operation: once the URI is > >> > >>rewritten, the proxy > >> > >>>won't rewrite again when the request spirals. For Route > >> > >>this is not the > >> > >>>case. OTOH, if there are any Route headers the proxy shouldn't be=20 > >>>rewriting / adding a route in the first place, > >> > >>No. Consider the case of a Path headers. In this case, the=20 > home proxy=20 > >>would populate the Route headers from the path set, and=20 > then push the=20 > >>UA route as the *last* Route header field. But anyway I don't=20 > >>understand the issue you are raising with spiraling. On=20 > each spiral, a=20 > >>new Route gets pushed. If instead you had R-URI rewriting, the only=20 > >>way the request would get back to the proxy is if the r-uri=20 > pointed to=20 > >>that proxy, and upon arriving there it would be rewritten again. > >>So there is > >>no difference. > >> > >>-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 > >> > >>_______________________________________________ > >>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 > --=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 From sip-bounces@ietf.org Wed Oct 04 16:44:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDZk-00032I-U3; Wed, 04 Oct 2006 16:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVDZj-0002zf-CE for sip@ietf.org; Wed, 04 Oct 2006 16:42:43 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVDZh-00023k-TN for sip@ietf.org; Wed, 04 Oct 2006 16:42:43 -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 k94KgQl02649; Wed, 4 Oct 2006 16:42:26 -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] GRUU and Grid alternative Date: Wed, 4 Oct 2006 15:42:10 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF69@zrc2hxm2.corp.nortel.com> In-Reply-To: <45240A5B.3000103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: Acbn6rFivwAWBLnGQ7GmdmO6z7OPdQACTZeg From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Looking at RFC-3455, and how the P-Called-Party-ID header is defined, there are some implications that weren't represented in the approach below that I think we should consider. For instance, Section 6.2 of RFC-3455 brings up a good point about the security and privacy issues around using the P-Called-Party-ID header. If the proposed mechanism is used to obviate the need for this header, or otherwise used to mimic the header's purpose we would have to address those concerns. Further, Section 4.2.2.1 states that the UAC MUST NOT insert a P-Called-Party-ID header field in any SIP request. This is because this it would potentially violate the transitive trust statement of applicability given in Section 1 of RFC-3455. I believe, by relying on the value of the R-URI specified by the UAC if this mechanism replaces the P-Called-Party-ID header, we'd be violating the spirit of Section 4.2.2.1 of RFC-3455. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, October 04, 2006 2:24 PM > To: Stucker, Brian (RICH1:AR00) > Cc: IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 > I don't follow. The only P-header issue this solves is=20 > P-Called-Party-ID. That header was added to deal exactly with=20 > this issue of the r-uri being rewritten, so the UAS doesn't=20 > know which public identity was targeted by the request. By=20 > not rewriting the request URI that problem is eliminated. >=20 > What trust-domain issues are you referring to? >=20 > -Jonathan R. >=20 > Brian Stucker wrote: >=20 > > I believe what you are describing here is essentially extending the=20 > > routing mechanism used within the IMS core network to route=20 > messages=20 > > between various servers (x-CSCFs, BGCFs, App Servers, etc). > >=20 > > Although this may help with a number of issues, and on the=20 > face of it=20 > > is a relatively simple idea (use a separate stack data=20 > structure for=20 > > routing instead of a static URI) I don't think it solves all the=20 > > problems you may think it does. > >=20 > > For instance, existing P-headers also have a trust-domain=20 > and network=20 > > assertion factor associated with them. > >=20 > > Regards, > > Brian > >=20 > >=20 > >>-----Original Message----- > >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >>Sent: Wednesday, September 27, 2006 12:50 AM > >>To: IETF SIP List > >>Subject: [Sip] GRUU and Grid alternative > >> > >>During our call on GRUU last week, there was a discussion on this=20 > >>issue that ekr raised, where he would like to see the grid usable=20 > >>outside of just gruu, i.e., with any AOR. > >> > >>During the call, I made a suggestion for an alternative=20 > solution, and=20 > >>there was agreement amongst those on the call for the proposed=20 > >>approach. > >> > >>The basic idea would be to remove the grid mechanism=20 > entirely from the=20 > >>gruu draft. Instead, a separate specification would be=20 > developed which=20 > >>would allow for loose routing to apply to user agents. So,=20 > consider a=20 > >>UA which registers. It would include a contact and a=20 > Supported header=20 > >>field with the value "ua-route". The registrar, assuming it=20 > >>understands this, notes that the UA supports UA loose routing and=20 > >>stores the contact. When an incoming call arrives for the=20 > AOR, rather=20 > >>than rewriting the R-URI with the registered contact, it pushes the=20 > >>registered contact into a Route header and leaves the R-URI alone=20 > >>(assuming the registered UA supports this mechanism). > >> > >>How does this solve the grid problem? Lets say my AOR is=20 > >>sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some=20 > arbitrary=20 > >>parameter, say sip:jdrosen@cisco.com;foo=3Dbaz, and hand it=20 > out to some=20 > >>correspondent. When a correspondent sends a request to that URI, it=20 > >>arrives at my home proxy. From there, since the R-URI is NOT=20 > >>rewritten, the entire URI, parameters and all, is passed to the UA.=20 > >>Thus, the UA knows the URI that was de-referenced. We wouldn't=20 > >>necessarily have to standardize a specific URI parameter,=20 > like grid,=20 > >>to carry the opaque data. > >> > >>This trick solves a whole bunch of other problems too. It would=20 > >>eliminate the need for the IMS P-Called-Party-ID header=20 > field, and it=20 > >>would help clarify when a request is retargeted (change in=20 > R-URI) vs. > >>when its just being delivered to the recipient (no change in R-URI). > >> > >>Comments? > >> > >>-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 > >> > >>_______________________________________________ > >>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 > --=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 From sip-bounces@ietf.org Wed Oct 04 17:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVE1Y-0000GH-KB; Wed, 04 Oct 2006 17:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVE1W-0000Fg-FS for sip@ietf.org; Wed, 04 Oct 2006 17:11:26 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVE1U-0006eh-6Q for sip@ietf.org; Wed, 04 Oct 2006 17:11:26 -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 k94LBN30017314; Wed, 4 Oct 2006 16:11:23 -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 k94LBNh03029; Wed, 4 Oct 2006 16:11:23 -0500 (CDT) Message-ID: <4524237B.5020308@lucent.com> Date: Wed, 04 Oct 2006 16:11:23 -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] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <45231E0E.80803@lucent.com> <001c01c6e780$eaae9d20$0601a8c0@BEMBUSTER> In-Reply-To: <001c01c6e780$eaae9d20$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 >> Forking coupled with response aggregation of 401/407 is another >> reason why the responses balloon. R-R headers added with all kinds >> of state is yet another. > > I think it would be good if the draft provided some text on this. OK; will put in some introductory text in next revision. > For starters: the current draft does not help in case of large > responses due to forking+401/407 aggregation as you describe here. Ummm ... AFAIK, it does. In such a case, the proxy, acting as a UAS will aggregate the responses, and if > 1500 bytes, send a 141 first. In all probability, a large UDP response between a proxy and a UAC in the same domain will succeed. Problem cases are those agents that are separated by WAN links and NATs. >> Possibly so; but all the same, I think they can be a valuable feed- >> back to the UAC. One thing we have struggled with in the SIPS >> debate is that there is no backwards feedback to the UAC if a >> downgrade occurs. Here, there is some explicit feedback that the >> UAC may find pertinent. > > There may be situations where this is valuable feedback. However, > it seems orthogonal to large UDP responses (i.e. solution for > different problem) All things being equal, I think this feedback is germaine enough that retaining it may be worthwhile. > Suppose the UAS sends a response of 1510 bytes over TCP. The next > upstream proxy removes the topmost Via, making the response smaller than > 1500 bytes, and then forwards it over UDP. In this case there is no > response > 1500 travelling over UDP, even though the UAS sent a response > larger than 1500 bytes and there is UDP in the chain OK, I see. This makes the entity that is ready to send the response be responsible for sending a 141, as you suggested in your email. 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 Oct 04 17:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVE3P-0003uB-Mp; Wed, 04 Oct 2006 17:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVE3O-0003ty-1T for sip@ietf.org; Wed, 04 Oct 2006 17:13:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVE3M-0006ux-NX for sip@ietf.org; Wed, 04 Oct 2006 17:13:22 -0400 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k94KGNm5020580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Oct 2006 15:16:25 -0500 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A0007FE@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A0007FE@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Use of Require header field in connected-identity Date: Wed, 4 Oct 2006 16:13:14 -0500 To: "Elwell, John" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: SIP , 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 On Oct 2, 2006, at 2:39 PM, Elwell, John wrote: > During WGLC I received a comment from Paul that when sending a mid- > dialog request with a changed From header field URI, we should also > include a Require header field with option tag id-change. In theory > it should not be needed, because the peer UA will already have > indicated id-change in the Supported header field, so it is known > to support the capability. Paul's rationale was to include the > Require header field in case something had gone wrong. > > I heard no other comment in favour of or against this. My opinion > is that it is unnecessary - if something of this nature has gone > wrong, then it is hard to be sure that simply including the Require > header field will be sufficient to avoid further problems. > Furthermore, if we specify use of the Require header field, it > would mean we have to specify what to do if we get back a 420. So > on balance I am against making this change. > > Any other opinions? How about including in the draft a discussion of why the Require: usage isn't useful? ;-) -- 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 Oct 04 18:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEpG-0007Fy-B9; Wed, 04 Oct 2006 18:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVEpE-0007Fp-NS for sip@ietf.org; Wed, 04 Oct 2006 18:02:48 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVEpD-0001sJ-BF for sip@ietf.org; Wed, 04 Oct 2006 18:02:48 -0400 Received: (qmail 25891 invoked by uid 0); 4 Oct 2006 22:02:44 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Oct 2006 22:02:44 -0000 Message-ID: <020901c6e800$d1c1f070$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <45231E0E.80803@lucent.com> <001c01c6e780$eaae9d20$0601a8c0@BEMBUSTER> <4524237B.5020308@lucent.com> Subject: Re: [Sip] I-D on handling large UDP responses Date: Thu, 5 Oct 2006 00:02:43 +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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 >> For starters: the current draft does not help in case of large responses >> due to forking+401/407 aggregation as you describe here. > > Ummm ... AFAIK, it does. In such a case, the proxy, acting as > a UAS will aggregate the responses, and if > 1500 bytes, send > a 141 first. In all probability, a large UDP response between > a proxy and a UAC in the same domain will succeed. Problem > cases are those agents that are separated by WAN links and NATs. The "acting as a UAS" bit is not how I interpret RFC3261 section 16.7 point 7 (it reads as if the proxy is forwarding one of the received 401/407 responses and adds headers from the others to that), but I suppose it could work in this way. Needs to be spelled out though... 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 Oct 04 22:06:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIYr-0004Df-L5; Wed, 04 Oct 2006 22:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIYp-0004DZ-Gs for sip@ietf.org; Wed, 04 Oct 2006 22:02:07 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVIYo-0002aQ-Al for sip@ietf.org; Wed, 04 Oct 2006 22:02:07 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <200610050201360130047boue>; Thu, 5 Oct 2006 02:02:01 +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 k9521BUm011915 for ; Wed, 4 Oct 2006 22:01:11 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k9521BPg011911; Wed, 4 Oct 2006 22:01:11 -0400 Date: Wed, 4 Oct 2006 22:01:11 -0400 Message-Id: <200610050201.k9521BPg011911@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1159971838.2732.20.camel@sukothai.pingtel.com> (slawrence@pingtel.com) Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <1159971838.2732.20.camel@sukothai.pingtel.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 In regard to 140's sent by proxies when about to send an oversized request: I forgot that 1xx's other than 100 can have a missing to-tag, but that is so. (section 13.2.2.1) But within-dialog requests have to-tags and demand responses that do, too, so I'd say that the 140 should have a to-tag if and only if the request does. (If an initial request elicited a 140 with a to-tag, the to-tag would necessarily be different from any UAS's to-tag, and the UAC might construct an early dialog for it.) We might be able to reduce the number of 140's by having the proxy in question add a (short!) parameter to the Via of the outgoing request indicating "140 already sent for this request". Then a proxy would not generate a 140 for a request that had this flag on a Via. 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 Oct 04 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIoY-0006ZC-OP; Wed, 04 Oct 2006 22:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVIoW-0006MX-NV for sip@ietf.org; Wed, 04 Oct 2006 22:18: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 1GVIoV-0007Vh-4h for sip@ietf.org; Wed, 04 Oct 2006 22:18:20 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 Oct 2006 19:18:19 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAAEEHJEWMDAkOKg X-IronPort-AV: i="4.09,257,1157353200"; d="scan'208"; a="344688218:sNHT28445372" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k952IIAt026760; Wed, 4 Oct 2006 19:18:18 -0700 Received: from [12.182.170.79] (sjc-vpn2-823.cisco.com [10.21.115.55]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k952Gmj0017130; Wed, 4 Oct 2006 19:18:14 -0700 (PDT) In-Reply-To: <4523FEEF.1080501@cisco.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Wed, 4 Oct 2006 19:24:39 -0400 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=5007; t=1160014698; x=1160878698; c=relaxed/simple; s=sjdkim3002; 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]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DAyadtlHzVE2lqPGk6mddYA9NTlg=3D; b=QCzLCGnStgGW4TOSXL5w3GhirfAJvlj5iqrSFrKE3XpRj9NeHezs6kBm48yJT5ukynEn8nzL gVG9CsC2ItJy96xkNUD3B8VED3wdEfUUTx9Ak78bYi2yL/uTFQ/p55GM; Authentication-Results: sj-dkim-3.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: SIP , Pete Cordell , Robert Sparks , 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 inline but yes basically agree with you ... On Oct 4, 2006, at 2:35 PM, Michael Thomas wrote: > Cullen Jennings wrote: > >> >> On Oct 3, 2006, at 12:52 PM, Robert Sparks wrote: >> >>> >>> I take it you are explicitly objecting to the statement that MD5 >>> is a reasonable non-normatively specified choice? >>> You have also clearly objected to 128 as a suggestion (The text >>> does NOT mandate a length). >>> >>> RjS >> >> >> Yes - MD5 is a cryptographic hash and I thought we all agreed >> that use off cryptographic hash was not the best choice. If we >> think cryptographic hash ideas are a good idea, then we need to >> explain why. >> >> Using a cryptographic hash, even in an example, is a huge red >> flag for any security person reviewing this. The fact that we >> used this particular one which has significant security issues, >> is a even bigger issue. > > Uh, no. These aren't even remotely comparable. I'm going to make a > big leap here > and guess that people aren't trying to actively _attack_ these > forking hashes. _That's_ > the problem with MD5 with security. If you're just using it as a > _hashing_ algorithm > that has a low probability of collisions, it's just fine. That is: > unless you're going to > say that the forking hash needs to be resisitant to collisions from > an attacker's chosen > text to do something nefarious, the problems with MD5 (or SHA1) > don't apply. yes - agree - all we need is something with low probability of collision, and the value of "low" is based on probability of call failing and having to be retried, not some security violation > >> Partially I think MD5 is totally lame to use here because it is >> slow and offer no advantages over better things and partially I >> am trying to avoid any delays due to security review where >> someone points out we should not be using MD5 in new protocols. > > The only knock in my mind is that it may be slower than something > else, Yes - I should have been clearer - that was my only concern. And even with that, I've never been a believer that the performance mattered much but many people in the WG have expressed that we have to do O (N^2) where N=30 or 70 depending on who you follow and this was a huge deal. I just wanted to take this performance argument off the table. > but I'd > worry a great deal about the "something else" if collisions are a > problem. Just randomly > inventing a good hashing algorithm with good collision properties > especially with > similar chosen text is not exactly the easiest thing to do. 100% agree - I'm not a fan of roll your own solution to hashes. Actually people still make fun of me for a project where I created in a hash table that only generated even numbers. Since then I have always been concerned about getting burned from things I rolled myself. > Since you're relying on this > for carrying state, I think it's a bad idea to not at least do a > SHOULD level algorithm(s) > and be very certain that the algorithm you choose actual has the > collision resistance > needed. I'm not an expert here by any means, but my recollection is > that CRC does > NOT have very good properties that way. CRC has poor whitening characteristics but it collision distribution if fairly uniform. All of this is weighted off against how many bits collision detection do we use. Keep in min that we have up to 70 things that we don't want to collide with a something like 1 in fives nines probability of collision. WIth a good hash we could likely do this in something like 15 bits (WAG), with a crappy hash we need a few more bits. We are talking about using insanely more bits than this (32 bits) so I'm not that worried. I would be worried with a CRC16. Also, as you point out, we are not trying to protect against a case where an attacker deliberately generates a collision in which case CRC would be a very bad choice. I think there are a huge number of things that could work fine and don't care what we choose - but since people are claiming that we should not use this loop detection because it is slow, I want the some reasonable fast hash to compare to. > > Mike > > >> If the we can't figure out a reasonable hash to suggest, how >> should an implementer figure out what to use. I've been trying to >> say, I don't care what but don't choose a cryptographic one. If >> people have a good reason for wanting MD5, I'm glad to listen but >> I just had not heard the reason yet. >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 05 00:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKXW-00036p-Fz; Thu, 05 Oct 2006 00:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVKXV-00036j-It for sip@ietf.org; Thu, 05 Oct 2006 00:08:53 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVKXU-0003Mm-B5 for sip@ietf.org; Thu, 05 Oct 2006 00:08:53 -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 k9548hGw009695; Wed, 4 Oct 2006 23:08:45 -0500 (CDT) Received: from [135.244.33.164] (vkg.lra.lucent.com [135.244.33.164]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k9548hh06677; Wed, 4 Oct 2006 23:08:43 -0500 (CDT) Message-ID: <45248547.9070503@lucent.com> Date: Wed, 04 Oct 2006 23:08:39 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <1159971838.2732.20.camel@sukothai.pingtel.com> <200610050201.k9521BPg011911@dragon.ariadne.com> In-Reply-To: <200610050201.k9521BPg011911@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: 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 Dale.Worley@comcast.net wrote: > We might be able to reduce the number of 140's by having the proxy in > question add a (short!) parameter to the Via of the outgoing request > indicating "140 already sent for this request". Then a proxy would > not generate a 140 for a request that had this flag on a Via. This is interesting -- but if a proxy, P1, switches to TCP from UDP, and sends a 140, then chances are that all proxies downstream from P1 will use TCP as well (for the same reason that P1 did -- the request was over 1500 bytes). So, a 140 should happen only once, and not at every hop. - 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 Oct 05 00:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVL7J-0007Iw-7l; Thu, 05 Oct 2006 00:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVL7G-0007Eo-Ru for sip@ietf.org; Thu, 05 Oct 2006 00:45:50 -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 1GVL7F-00030j-HR for sip@ietf.org; Thu, 05 Oct 2006 00:45:50 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 04 Oct 2006 21:45:49 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k954jnMs018164; Wed, 4 Oct 2006 21:45:49 -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 k954jmin017829; Wed, 4 Oct 2006 21:45:48 -0700 (PDT) Received: from [192.168.0.102] (sjc-vpn1-1050.cisco.com [10.21.100.26]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k954YbR6005607; Wed, 4 Oct 2006 21:34:37 -0700 Message-ID: <45248E06.305@cisco.com> Date: Wed, 04 Oct 2006 21:45:58 -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: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> In-Reply-To: <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3006; t=1160023549; x=1160887549; c=relaxed/simple; s=sjdkim1002; 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]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DVcADUG4YAjhJCOUESy9WKP9y43s=3D; b=fwglyzvTt1lHdnVTjfJGanfKdGRyhl+wyiwn8sT84L98mNkAwL/jGeFSF9hfwEg0vcPDKpQx 4+vk5lskZXAwHJW8yQyAYWD1e7rDZJiU0jDzoF5ZqE8rjSf7d7gDqAJR; X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: SIP , Pete Cordell , Robert Sparks , 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 Cullen Jennings wrote: >> >> The only knock in my mind is that it may be slower than something else, > > > Yes - I should have been clearer - that was my only concern. And even > with that, I've never been a believer that the performance mattered > much but many people in the WG have expressed that we have to do O > (N^2) where N=30 or 70 depending on who you follow and this was a > huge deal. I just wanted to take this performance argument off the > table. It's probably not worth belaboring this too much, but I do worry about not constraining this such that roll your own is a likely outcome. Which is why I said that a SHOULD strength algorithm(s) seems pretty reasonable. > >> but I'd >> worry a great deal about the "something else" if collisions are a >> problem. Just randomly >> inventing a good hashing algorithm with good collision properties >> especially with >> similar chosen text is not exactly the easiest thing to do. > > > 100% agree - I'm not a fan of roll your own solution to hashes. > Actually people still make fun of me for a project where I created in > a hash table that only generated even numbers. Since then I have > always been concerned about getting burned from things I rolled myself. hmm, malloc (tablesize/2); hashvalue /= 2; and it's all of a sudden not so embarassing :) > > >> Since you're relying on this >> for carrying state, I think it's a bad idea to not at least do a >> SHOULD level algorithm(s) >> and be very certain that the algorithm you choose actual has the >> collision resistance >> needed. I'm not an expert here by any means, but my recollection is >> that CRC does >> NOT have very good properties that way. > > > CRC has poor whitening characteristics but it collision distribution > if fairly uniform. All of this is weighted off against how many bits > collision detection do we use. Keep in min that we have up to 70 > things that we don't want to collide with a something like 1 in fives > nines probability of collision. WIth a good hash we could likely do > this in something like 15 bits (WAG), with a crappy hash we need a > few more bits. We are talking about using insanely more bits than > this (32 bits) so I'm not that worried. I would be worried with a > CRC16. Also, as you point out, we are not trying to protect against a > case where an attacker deliberately generates a collision in which > case CRC would be a very bad choice. I'm good for whatever is appropriate here -- my main point is that using things like md5 for non-crypto strength hashes shouldn't be dismissed if you're using it just as a _hash_ algorithm. And if that causes knee-jerks on the IESG, etc, it would be good to get that out of the way. My suspicion is that it wouldn't though once it was clear that it was just being used as a hash for non-crypto reasons. Mike, rehabilitaton-R-us. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 03:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNFO-0002kO-Aw; Thu, 05 Oct 2006 03:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNFL-0002kI-84 for sip@ietf.org; Thu, 05 Oct 2006 03:02:19 -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 1GVNFG-0006bE-M3 for sip@ietf.org; Thu, 05 Oct 2006 03:02:19 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6N00L01I7ROA@siemenscomms.co.uk> for sip@ietf.org; Thu, 05 Oct 2006 08:02:15 +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 <0J6N00K9FI7R9X@siemenscomms.co.uk>; Thu, 05 Oct 2006 08:02:15 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SS5BH>; Thu, 05 Oct 2006 08:02:02 +0100 Content-return: allowed Date: Thu, 05 Oct 2006 08:02:01 +0100 From: "Elwell, John" Subject: RE: [Sip] Use of Require header field in connected-identity To: Dean Willis Message-id: <50B1CBA96870A34799A506B2313F26670A04105B@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: 50a516d93fd399dc60588708fd9a3002 Cc: SIP , 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 Dean, Good idea. I will include the following: "By sending a request with a changed From header field URI only to targets that have indicated support for this option, there should be no need to send this option tag in a Require header field." Also, following a suggestion from Cullen I will change the tag name to "from-change". John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 04 October 2006 22:13 > To: Elwell, John > Cc: SIP; Paul Kyzivat > Subject: Re: [Sip] Use of Require header field in connected-identity > > > On Oct 2, 2006, at 2:39 PM, Elwell, John wrote: > > > During WGLC I received a comment from Paul that when sending a mid- > > dialog request with a changed From header field URI, we > should also > > include a Require header field with option tag id-change. > In theory > > it should not be needed, because the peer UA will already have > > indicated id-change in the Supported header field, so it is known > > to support the capability. Paul's rationale was to include the > > Require header field in case something had gone wrong. > > > > I heard no other comment in favour of or against this. My opinion > > is that it is unnecessary - if something of this nature has gone > > wrong, then it is hard to be sure that simply including the > Require > > header field will be sufficient to avoid further problems. > > Furthermore, if we specify use of the Require header field, it > > would mean we have to specify what to do if we get back a 420. So > > on balance I am against making this change. > > > > Any other opinions? > How about including in the draft a discussion of why the Require: > usage isn't useful? ;-) > > -- > 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 Oct 05 05:00:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVP28-0007R7-Mf; Thu, 05 Oct 2006 04:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVP26-0007R1-IX for sip@ietf.org; Thu, 05 Oct 2006 04:56:46 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVP25-0001JJ-AJ for sip@ietf.org; Thu, 05 Oct 2006 04:56:46 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k958udke003403 for ; Thu, 5 Oct 2006 03:56:40 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Oct 2006 16:56:05 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Oct 2006 16:56:05 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Thu, 5 Oct 2006 16:56:04 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Use of Require header field in connected-identity thread-index: AcboTHcRZj6CbstpS5ugSOvY8yQmAwAD1Raw From: "Xia, Zhi Feng \(Bruce\)" To: "SIP" X-OriginalArrivalTime: 05 Oct 2006 08:56:05.0337 (UTC) FILETIME=[175EEC90:01C6E85C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] An reference error in rfc 3420 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, There's a reference error in 3420: >>>>>>>> Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3265, June 2002. = ^^^^^^^^^^^^^should be RFC3261 Regards, Zhifeng _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 07:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRCC-00073a-Jj; Thu, 05 Oct 2006 07:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRCA-0006zA-Nb for sip@ietf.org; Thu, 05 Oct 2006 07:15:18 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVRC4-0002Bn-4L for sip@ietf.org; Thu, 05 Oct 2006 07:15:18 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 950A68F3 for ; Thu, 5 Oct 2006 13:14:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 13:14:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Oct 2006 13:14:53 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB59403E0E204@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using outbound for multiple registrations - even if there are no NATs. Thread-Index: Acbob3uNbQmbxelIQnqf4UEI2OygnQ== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 05 Oct 2006 11:14:54.0016 (UTC) FILETIME=[7BA67C00:01C6E86F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Sip] Using outbound for multiple registrations - even if there are no NATs. X-BeenThere: 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="===============1566311680==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1566311680== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E86F.7BB7E8A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E86F.7BB7E8A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In 3GPP it is discussed how to support multiple registrations from a terminal. A use-case is when a terminal have multiple accesses, and wants to register via all of them. One of the solutions that have been presented is to use the outbound mechanism. The only issue I can find is the use of STUN for keep-alive. In case there are no NATs between the terminal and the outbound proxy (read: P-CSCF) there is of course no need for keep-alives. I know this is not the original idea behind outbound, but I still outbound could be a very good candidate to implement this. Comments? Regards, Christer ------_=_NextPart_001_01C6E86F.7BB7E8A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Using outbound for multiple registrations - even if there are no = NATs.

Hi,

In 3GPP it is discussed how to support = multiple registrations from a terminal. A use-case is when a terminal = have multiple accesses, and wants to register via all of = them.

One of the solutions that have been = presented is to use the outbound mechanism.

The only issue I can find is the use of = STUN for keep-alive. In case there are no NATs between the terminal and = the outbound proxy (read: P-CSCF) there is of course no need for = keep-alives.

I know this is not the original idea = behind outbound, but I still outbound could be a very good candidate to = implement this.

Comments?

Regards,

Christer



------_=_NextPart_001_01C6E86F.7BB7E8A9-- --===============1566311680== 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 --===============1566311680==-- From sip-bounces@ietf.org Thu Oct 05 07:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRjS-0004mM-Ki; Thu, 05 Oct 2006 07:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVRjQ-0004m4-RP for sip@ietf.org; Thu, 05 Oct 2006 07:49:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVRjK-0007zI-On for sip@ietf.org; Thu, 05 Oct 2006 07:49:40 -0400 Received: (qmail invoked by alias); 05 Oct 2006 11:49:33 -0000 Received: from dyn-160-39-243-37.dyn.columbia.edu (EHLO [160.39.243.37]) [160.39.243.37] by mail.gmx.net (mp015) with SMTP; 05 Oct 2006 13:49:33 +0200 X-Authenticated: #29516787 Message-ID: <4524F151.8000208@gmx.net> Date: Thu, 05 Oct 2006 13:49:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ECRIT , GEOPRIV , IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] Remote Participation at the SDO Emergency Service 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, this is a reminder that you can participate remotely at the SDO Emergency Service Workshop. For instructions see: http://www.ietf-ecrit.org/EmergencyWorkshop2006 Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 09:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTM0-0006BI-Du; Thu, 05 Oct 2006 09:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVTLy-0006BC-Jo for sip@ietf.org; Thu, 05 Oct 2006 09:33:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVTLp-0005pC-Gy for sip@ietf.org; Thu, 05 Oct 2006 09:33:34 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 66F984F0094; Thu, 5 Oct 2006 15:33:22 +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, 5 Oct 2006 15:33:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 15:33:21 +0200 Received: from [131.160.36.18] (EH3I2003TGFCPET-131160036018.lmf.ericsson.se [131.160.36.18]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B848B233C; Thu, 5 Oct 2006 16:33:21 +0300 (EEST) Message-ID: <452509A1.1040708@ericsson.com> Date: Thu, 05 Oct 2006 16:33:21 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Miguel Garcia References: <451F9D7D.4040008@nokia.com> In-Reply-To: <451F9D7D.4040008@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 13:33:21.0851 (UTC) FILETIME=[D38180B0:01C6E882] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip Subject: [Sip] Re: [Sipping] URI list for INVITE X-BeenThere: sip@ietf.org X-Mailman-Version: 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, [moving this thread to SIP] Different servers implement different services. The draft you point to describes how to provide the list of participants for a particular service: a conferencing service. Note that the conferencing service is defined in a different set of documents. So, if you want to define a different service, you should go ahead define it, and then explain UAs provide the server with the data it needs to execute the service. Regarding your examples, if you want to influence how routing is performed, you may want to look at caller preferences. Cheers, Gonzalo Miguel Garcia wrote: > Hi Darshan: > > The mechanism described in draft-ietf-sip-uri-list-conferencing does > what you describe, at least at the high-level: It allows a user to send > a single INVITE request to a URI-list server (which is effectively a > conference server), to set up a conference with a number of invitees. > > However, it seems from your e-mail that you want something else than > this function. Use case 1 does not end up in setting up a conference, so > you don't need a conference server. So it looks like something different > in essence. > > The three cases that you are describing imply two different mechanisms: > one to carry the list of invitees, the other to carry a strategy (or > policy) to contact those invitees e.g., whether to use sequential, > parallel, or a mixed strategy. > > So, I think what is missing from draft-ietf-sip-uri-list-conferencing is > a mechanism where the sender of the request can convey a policy to > contact those URIs. Then it is up to the URI-list server to accept the > policy or not. This policy conveyance seems to be an additional building > block that the mentioned draft. It may have some parallelism with the > fork-directive of the caller preferences (RFC 3841). > > /Miguel > > Darshan Bildikar wrote: >> List, >> >> I have recently gone through three drafts that I found interesting >> "draft-ietf-sip-uri-list-subscribe" - That allows a UA to create a >> subscription to a list of resources in SIP >> >> >> "draft-ietf-sip-uri-list-conferencing" - Allows conference creation using >> SIP URI list services. >> "draft-ietf-sip-multiple-refer" - Refer a server to multiple resources. >> My understanding is that these drafts allow SIP requests to map to >> multiple >> resources in order to avoid sending multiple requests. >> In this regard, I was wondering whether it can be extended to an INVITE >> request too! That is, the mechanism defined in >> "draft-ietf-sip-uri-list-conferencing" can be extended to normal INVITE >> requests. The basic requirement is to allow an INVITE request to address >> multiple AOR's. >> I know I am describing what is typically handled in by proxies through >> parallel/sequential forking. But as I understand it, there is no >> mechanism >> (correct me if I am wrong) to indicate to a server WHETHER to carry out >> sequential or parallel forking. Also it is not currently possible to >> use a >> combination of the two. Consequently, I can think of a few use cases >> where >> in this information might be provided as user input. Some of them are >> presented below >> >> Use Case 1: Alice would like to indicate through an interface on her GUI >> soft phone or a web page that she would like to talk to either Bob or >> Carol. >> Note that Bob and Carol have different AOR's registered that MAY map to >> multiple devices as indicated during REGISTRATION. >> >> Use Case 2: A user could indicate through a web page for example, that he >> wishes to talk to either of three people Alice, Bob or Carol. She wants >> Alice and Bob to be tried in PARALLEL and if neither of them is available >> then she would like to talk to Carol. >> Use Case 3: It would allow a server to offer this as a primitive to >> requesting UA's i.e. a UA can request a server to "Route my call to a >> list >> of SIP URI's one by one". It could then be exposed as a "service" that >> could >> be invoked by enterprise applications through a generic interface (not >> necessarily SIP) >> >> In my opinion such a strategy would be of use when forking (using the >> term >> loosely here) information is available only in RUNTIME (possibly as user >> input) and cannot be configured statically in a proxy. >> I think this could be achieved by expanding the scope of >> "draft-ietf-sip-uri-list-conferencing" to make it more generic. We >> need even >> actually use a forking mechanism. An AS behaves as a B2BUA and >> generates a >> separate dialog for each SIP URI in the list. >> >> Thoughts/Comments? >> >> Darshan >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 10:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUQu-0002FW-Rh; Thu, 05 Oct 2006 10:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUQt-0002FP-FY for sip@ietf.org; Thu, 05 Oct 2006 10:42:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUQs-0001Sj-1U for sip@ietf.org; Thu, 05 Oct 2006 10:42:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2006 07:41:08 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="44954130:sNHT63614340" 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 k95EenQ9028837; Thu, 5 Oct 2006 10:40:49 -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 k95EemDM017698; Thu, 5 Oct 2006 10:40: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, 5 Oct 2006 10:40:48 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:40:47 -0400 Message-ID: <4525196F.5010103@cisco.com> Date: Thu, 05 Oct 2006 10:40:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Escaping rules of SIP-URI userpart References: <1ECE0EB50388174790F9694F77522CCF0D58BBC2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D58BBC2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 14:40:48.0015 (UTC) FILETIME=[3F3521F0:01C6E88C] DKIM-Signature: a=rsa-sha1; q=dns; l=5067; t=1160059249; x=1160923249; 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]=20Escaping=20rules=20of=20SIP-URI=20userpart |To:Francois=20Audet=20; X=v=3Dcisco.com=3B=20h=3DXEQ5Dcn4n1VJkRPH4Uij4F4mzIU=3D; b=OB5vF4js623r5wWF6bIvWD2RoWI9KqEXEkx+C5sOhb5N+0+eXIP+gycOjiJ1dVpSiSkmTwnv V/DQdMLRmPQ7vlBToGAYEG90p0ZqeM9TzyWH7JgyUvTY73D8l4/LOQJN; 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: 2beba50d0fcdeee5f091c59f204d4365 Cc: "Jesske, R" , sip@ietf.org, Juha Heinanen , "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 Francois, Philosophically I agree with you. But I have found in practice that it is pretty hard to avoid instances of this kind of usage. If everyone would agree that all services are to be built in the UA then it could work out, but that just isn't happening. Another solution would be some kind of framework for encoding requests for services in the network, that would work for all the things people want to do that way. (Something in the style of RFC4240 could be used I suppose, but would require some kind of agreement on encoding.) These typically aren't "published" URIs. Instead they are "constructed" URIs, and depend on configuration to ensure that they are constructed in such a way that they will arrive at something that knows how to deal with it. Its all pretty ugly, but I don't think we will be able to exclude this kind of usage. BUT, if it is going to be done then I think we ought to expect the escaping rules to be followed. Paul Francois Audet wrote: > It's a valid URI, yes, not necessarily a valid phone number. > > Certainly not a valid global phone number. > > The specific example mentioned (privacy=on) is very broken since > it really won't give you privacy at all. > > What bothers me with this thread is not that people want to use > strange characters in URIs. > > What bothers me is that people want to use it to replicate > analog telephone keypad codes, the same way it was done back then, > in SIP. It was broken then, and it is even more broken now that > addresses > are supposed to be global. > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: Friday, September 29, 2006 4:56 PM >> To: Audet, Francois (SC100:3055); Juha Heinanen >> Cc: Jesske, R; sip@ietf.org; Christer Holmberg (JO/LMF) >> Subject: Re: [Sip] Escaping rules of SIP-URI userpart >> >> Francois, >> >> As long as one adheres to the escaping rules, it is perfectly >> valid to use # in URIs. The UA should not attempt any >> interpretation, but simply escape-and-pass anything the user dials. >> >> The UA user interface can be such that '#' means end-of-input >> (ie ), but it is also valid on the wire (when escaped) >> >> Regards, >> >> jeroen >> >> ----- Original Message ----- >> From: "Francois Audet" >> To: "Juha Heinanen" >> Cc: "Jesske, R" ; ; >> "Christer Holmberg (JO/LMF)" >> Sent: Saturday, September 30, 2006 1:25 AM >> Subject: RE: [Sip] Escaping rules of SIP-URI userpart >> >> >> >> >> Francois Audet writes: >>> > There is no need for this in a URI. The service code >> should be > >>> translatable by the phone to a real URI that actually means > >>> something. >>> >>> i don't understand what you are trying to say. #31# prefix >> of phone >>> number, for example, means something to PSTN and needs to >> be carried >>> there from the SIP phone, which cannot have a clue of various PSTN >>> dial string conventions. or can you explain what kind of magic >>> translation nortel SIP phones do when user dial #31# followed by a >>> phone number? >> I'm saying doing what you are proposing, i.e., using # in a >> phone number ON THE WIRE (I.e., in a URI), is an extremely >> bad idea that we shouldn't attempt to do in SIP. And it won't >> work except in isolated proprietary implementations. >> >> In the example you gave (I'm hearing that some network >> operator is using this for privacy). >> >> What you need to do is intercept the digit pattern in the >> phone, make the call to the destination without the >> proprietary digits, and then mark your From header as >> anonymous@anonymous.invalid. >> >> To do it your way would MANDATE a B2BUA since my proxy would >> have to remove the From and replace it (making it a B2BUA). >> And it would magically have to understand all the dialling >> plans in the universe. >> >> So publishing a URI with a # means most people won't be able >> to reach it. #31# means absolutely nothing to me in North >> America. If I try to call you with this, it just won't work. >> >> As a side note, on many phones, "#" means end-of-dialling. >> It stops digit collection. And it is NOT transmitted on the wire. >> >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 05 11:00:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgA-0007yh-5G; Thu, 05 Oct 2006 10:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg7-0007ki-Tt for sip@ietf.org; Thu, 05 Oct 2006 10:58:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUZe-0003Cf-0C for sip@ietf.org; Thu, 05 Oct 2006 10:51:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 10:51:46 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105837429:sNHT52462352" 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 k95EpjG6032475; Thu, 5 Oct 2006 10:51:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k95EpjYL014580; Thu, 5 Oct 2006 10:51: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); Thu, 5 Oct 2006 10:51:45 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 10:51:44 -0400 Message-ID: <45251C00.5060102@cisco.com> Date: Thu, 05 Oct 2006 10:51:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Darshan Bildikar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 14:51:45.0020 (UTC) FILETIME=[C6D023C0:01C6E88D] DKIM-Signature: a=rsa-sha1; q=dns; l=1204; t=1160059905; x=1160923905; 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-implementors]=20Early=20media=20query |To:Darshan=20Bildikar=20; X=v=3Dcisco.com=3B=20h=3DmxutjAmxxH9oF7fqbi2EdjuF3PY=3D; b=ZU02276OSF/I5MjzvBik5qqp8M09EmN7SVT9iSQhg8OSImPkZ1uQofJBiBMEfLoNh/jfdBM/ assyDSj4/hLU8fZ6y39bUurju+VkdHYNjgXIU8//e47qf6UmIpjwNEQL; 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, 'Retesh Chadha' Subject: [Sip] Re: [Sip-implementors] Early media query X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Darshan Bildikar wrote: > I don't think that even Method 3 and 4 are OK because they will involve a > change in the origin line parameter of the SDP and that is not allowed as > per the RFC. Which RFC? I suport Crister's response. Paul > BTW, what was the rationale behind not allowing the origin line to change? > It makes implementing apps like prepaid and CRBT very difficult. Could > someone please throw some light on this? > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha > Sent: Monday, October 02, 2006 5:46 PM > To: Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Early media query > > Hi Udit > Of all the methods you have specified, Method 1 and 2 are wrong as per > the RFC which states that the sdp of all the provisional and 2xx > response of INVITE should be same if they are present. > > Both Method 3 and 4 look fine, with method 4 being better because in > that case 200 ok for INVITE is only sent when the final negotiation > (call media) is done. > > Hope this helps. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 11:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgq-0000zv-1v; Thu, 05 Oct 2006 10:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUgF-0008CI-2W; Thu, 05 Oct 2006 10:58:35 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUXx-0002ku-Q8; Thu, 05 Oct 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BEB8926E44; Thu, 5 Oct 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVUXx-0004Jb-L6; Thu, 05 Oct 2006 10: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: Thu, 05 Oct 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-acr-code-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 --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-03.txt Pages : 9 Date : 2006-10-5 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-03.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-03.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-03.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-10-5095033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-acr-code-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-acr-code-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-5095033.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 Oct 05 11:14:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUtI-0006e4-TV; Thu, 05 Oct 2006 11:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUtH-0006dc-3w for sip@ietf.org; Thu, 05 Oct 2006 11:12:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVUtF-0007CT-Gl for sip@ietf.org; Thu, 05 Oct 2006 11:12:03 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 08:12:01 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="328425283:sNHT64039108" 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 k95FC1dg026427; Thu, 5 Oct 2006 08:12:01 -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 k95FBsbX026387; Thu, 5 Oct 2006 08:12:00 -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); Thu, 5 Oct 2006 11:12:00 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 11:11:59 -0400 Message-ID: <452520BF.8020409@cisco.com> Date: Thu, 05 Oct 2006 11:11:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Darshan Bildikar Subject: Re: [Sip-implementors] [Sip] RE: Early media query References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Oct 2006 15:11:59.0921 (UTC) FILETIME=[9AF35210:01C6E890] DKIM-Signature: a=rsa-sha1; q=dns; l=4853; t=1160061121; x=1160925121; 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-implementors]=20[Sip]=20RE=3A=20=20Early=20media=20query; X=v=3Dcisco.com=3B=20h=3DpWuPGinZB3Q+tuGNbuoIOmfTwFI=3D; b=ppOTDRmu9k8hX2+29BSZ+DgqRchJ6NGehbJuD/bj72bnM7X//a+VddgE9K/sz1aGeb23T4bG Or8EvwYP8f+Xa9ESJl6JDKeE8mnp0dGIe9rJu5CrXiSAsbOoCiRpKJRN; 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: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, 'Retesh Chadha' X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I agree with you that 3 and 4 are invalid if the 2nd offer isn't a suitable modification of the first answer, and that is probably impractical if the announcement server and the final target are independent. The way you get around that is to either use flow 2, with different to-tags, or else you a flow something like a 3pcc transfer. In those flows, you send an offerless reinvite to the caller, and then send that as an offer to the target, then take the answer from the target and send it as answer to the caller. To work it out you need to expose more detail about the interactions between the various components. Paul Darshan Bildikar wrote: > Quoting RFC 3264 Section 8 > > > Nearly all aspects of the session can be modified. New streams can > be added, existing streams can be deleted, and parameters of existing > streams can change. When issuing an offer that modifies the session, > the "o=" line of the new SDP MUST be identical to that in the > previous SDP, except that the version in the origin field MUST > increment by one from the previous SDP > > Why I am saying there is a problem with this is because > > In the first answer you are probably giving the caller the announcement > server SDP (i.e. something like o=mediaserver) and then later updating it > with the callee SDP (i.e. something like o=calleeside). If you don’t have a > B2BUA in between that actually changes the origin line of SDP (i.e. to > something like o=APPSERVER) then the flows would actually be invalid because > of this restriction. > > The flows that are described are generally used. I am not saying that they > must not be used. What I am saying is that the RFC 3264 places a restriction > on them in terms of origin line. > > However, I don’t think this restriction is valid, coz if a change the IP is > allowed why not a change in origin line? > > This is what I am trying to get clarified. > > > ________________________________________ > From: Manpreet Singh [mailto:msingh@ibasis.net] > Sent: Tuesday, October 03, 2006 9:56 AM > To: Darshan Bildikar; 'Retesh Chadha'; Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: RE: [Sip] RE: [Sip-implementors] Early media query > Importance: High > > I would say 3 makes total sense as the Re-invite is happening after a dialog > is complete so not sure why the spec wont allow it. So it would be more or > less a mid call change ( in confirmed state ) happening from a callee side > which would be the application server trying to bridge the call to the > called party skipping the announcement server. 3 should work fine and the > origin field has to be changed because now the call needs to be bridged to > the called party which is a whole new endpoint supporting different codecs > with different connection identifiers etc. > I'd say why not just send the 200OK with the answer to the initial offer in > the Invite and then play the annoucement and then bridge using a re-invite. > Unless you are trying to save the time charged till the annoucement is > played, which a lot of prepaid apps try to do, then this thing gets > complicated. I guess in that case, the application server can send the > answer in rel-183 and then the moment the call needs to be bridged, send a > 200Ok and a re-invite, which is exactly what is shown in (3). > M > -----Original Message----- > From: Darshan Bildikar [mailto:dbildikar@ipunity.com] > Sent: Monday, October 02, 2006 11:56 PM > To: 'Retesh Chadha'; Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip] RE: [Sip-implementors] Early media query > I don't think that even Method 3 and 4 are OK because they will involve a > change in the origin line parameter of the SDP and that is not allowed as > per the RFC. > BTW, what was the rationale behind not allowing the origin line to change? > It makes implementing apps like prepaid and CRBT very difficult. Could > someone please throw some light on this? > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha > > Sent: Monday, October 02, 2006 5:46 PM > To: Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Early media query > Hi Udit > Of all the methods you have specified, Method 1 and 2 are wrong as per the > RFC which states that the sdp of all the provisional and 2xx response of > INVITE should be same if they are present. > Both Method 3 and 4 look fine, with method 4 being better because in that > case 200 ok for INVITE is only sent when the final negotiation (call media) > is done. > Hope this helps. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 11:31:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVA8-0001SC-2U; Thu, 05 Oct 2006 11:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVA6-0001Ro-7Z for sip@ietf.org; Thu, 05 Oct 2006 11:29:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVA3-0001Gq-H1 for sip@ietf.org; Thu, 05 Oct 2006 11:29:26 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2006 08:28:52 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="44962051:sNHT832548382" 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 k95FSli2025155; Thu, 5 Oct 2006 11:28:47 -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 k95FSkDO004307; Thu, 5 Oct 2006 11:28:47 -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); Thu, 5 Oct 2006 11:28:46 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 11:28:45 -0400 Message-ID: <452524AD.5080501@cisco.com> Date: Thu, 05 Oct 2006 11:28:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A00083E@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A00083E@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 15:28:45.0787 (UTC) FILETIME=[F27E4AB0:01C6E892] DKIM-Signature: a=rsa-sha1; q=dns; l=16434; t=1160062127; x=1160926127; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments) |To:=22Elwell,=20John=22=20; X=v=3Dcisco.com=3B=20h=3DxFpxC1XNdmtl1r/DEf+C1Z0YsQs=3D; b=ZveL/y3XirniELDZYl9xrUf4S0PaDggauqo/qJsWiwW4Qww3RNQHFaQfFaTqMfVCvST3KMJD iLnuIUa8ll5c8OjVfToQV0qOAdU2PPJiOYNDj6dwV2tPQT7kELeWC1Ni; 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: 4cbeb0f20efb229aa93fae1468d20275 Cc: Cullen Jennings , SIP , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > So your proposal is that the connected-identity RFC should update RFC 4474 > to somehow relax rules at a verifier. Correct? Yeah, I think so. > So the next question concerns the way in which these rules should be > relaxed. One problem with the verifier not being located at the UAS but at > some proxy is that the UAS might be configured always to trust identities > received in requests via the verifier's proxy if an Identity header field is > present, on the assumption that the signature has been checked by the > verifier. Therefore it sounds like the verifier, if it does not reject a > request with a bad signature, should remove the Identity header field (and > also Identity-Info) before forwarding the request towards the target. (I think I have seen someone propose combining the use of Identity and P-Asserted-Identity, though I don't recall the details, or which draft it was. So what I am about to say might bear no relationship to that.) I could see how Identity might be used between trust domains, while P-Asserted-Identity is used within a trust domain. In that case, a verifier might run at the entry point to a trust domain and if verification succeeds, insert a P-Asserted-Identity header with a corresponding identity. It then might, or might not, remove the Identity header. Recipients within the trust domain could then use P-Asserted-Identity as the source of identity info. (In this scenario, an identity header would only be added to requests when they leave the trust domain.) In this kind of environment, it is only necessary for the verifier to omit the P-Asserted-Identity header when verification fails. > Under what conditions should a verifier remove an Identity header field > rather than rejecting with 436/437/438? My inclination would be to leave it > as a matter of policy as far as the update to RFC 4474 is concerned, and > then make more precise statements concerning mid-dialog requests. > Alternatively the update to RFC 4474 could just relax the rules for > mid-dialog requests. I think there is some merit in relaxing the rules in > general, because otherwise there might be situations where a legitimate > caller cannot establish a call because an Authentication Service (outside > the UAC's control) is inserting an unverifiable signature (e.g., in > Identity-Info placing a URL that the Verifier cannot dereference for some > reason). What you say sounds reasonable to me. There is however some risk to having a verifier remove identity. The problem would be when there are potentially multiple verifiers that don't trust one another. If an early one removes the header, then it prevents a subsequent verifier from doing its own verification. This could come up if a request transits a domain on the way to another domain. Each domain may wish to do its own verification. That is an advantage to having the verifier add something to the request to indicate the result of its verification. > One consequence of the Verifier being separated from the UAS is that we > don't want to rely on stateful behaviour at the Verifier or its proxy (for > similar reasons that you cited for the Authentication Service earlier). So > for mid-dialog requests we would need to mandate, or at least recommend, > that 436/437/438 should not be sent. Right. Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 03 October 2006 01:44 >> To: Elwell, John >> Cc: Cullen Jennings; Jon Peterson; SIP >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >> draft-ietf-sip-connecte d-id entity-01 comments) >> >> >> >> Elwell, John wrote: >>> Thinking further on this, perhaps there is a 4th way: >>> >>> 4. Specify that if a UAS rejects a mid-dialog request with >> 436, 437 or 438, >>> then it MUST NOT invoke the verifier for a subsequent request >> This assumes that the verifier is invoked by the UAS, and not by some >> proxy in front of the UAS. Isn't it valid to have a verifier >> in a proxy >> before the UAS? This rule would forbid that, because it would >> cause that >> proxy to be call stateful. >> >> I think it would just be better to update the RFC, even >> though that is a >> bit more trouble than not to. >> >> Paul >> >>> on the same >>> dialog unless the From header field URI has changed, and in >> such cases >>> SHOULD NOT make use of the unverified connected-identity. >> Then a UAC, on >>> receiving 436, 437 or 438, MUST repeat the request once. >> This would allow >>> business as usual on this dialog (but without the benefit >> of connected >>> identity, therefore no worse than at present). It avoids >> any change to RFC >>> 4474, because verification is optional anyway. >>> >>> Would this work? >>> >>> John >>> >>>> -----Original Message----- >>>> From: Elwell, John >>>> Sent: 26 September 2006 21:02 >>>> To: Cullen Jennings; Jon Peterson >>>> Cc: SIP; Paul Kyzivat >>>> Subject: FW: Rejecting connected identity (was RE: >>>> draft-ietf-sip-connected-id entity-01 comments) >>>> >>>> Cullen, Jon, >>>> >>>> In case you missed this (it wasn't addressed directly to >>>> you), I would greatly appreciate an opinion from each of you >>>> on this remaining issue in connected-identity. Just to >>>> summarise, RFC 4474 leaves it up to policy whether to return >>>> a 428 response if Identity is missing, but mandates the >>>> sending of a 436, 437 or 438 response for certain errors >>>> arising while verifying the signature. It seems that for mid >>>> dialog requests this behaviour could be harmful. What does >>>> the UAC for the mid dialog request do if it receives 436, 437 >>>> or 438? If the mid-dialog request was solely for the purpose >>>> of connected identity, it can give up and allow the call to >>>> continue as is. But if the request was for some other purpose >>>> (e.g., renegotiating the session because of hold, say, or >>>> session timer refresh), the UAC really wants it to work. For >>>> the normal case where the Authentication Service is at a >>>> proxy, not at the UAC, the UAC cannot force the >>>> Authentication Service to refrain from putting this >>>> unverifiable signature in the mid-dialog request, so any >>>> attempts to repeat the request would most likely be doomed to >>>> getting the same response. >>>> >>>> It seems there are three things we could do, none very attractive: >>>> 1. Get connected-identity to modify the procedures of RFC >>>> 4474 for a verifier by softening the requirements for sending >>>> 436, 437 and 438 in response to mid-dialog requests. But then >>>> a mid-dialog request from a rogue source would be accepted. >>>> 2. Say that the Authentication Service should omit the >>>> signing of mid-dialog requests if a previous attempt has >>>> resulted in 436, 437 or 438. But this implies statefulness >> at the AS. >>>> 3. Accept the fact the mid-dialog requests can fail in this >>>> way and therefore things like session refresh and session >>>> renegotiation cannot be done, probably resulting in call >>>> failure. Sounds bad, but it is no different from an initial >>>> INVITE request, where there is nothing the UAC can do if the >>>> AS inserts an Identity header that gets rejected with 436, >> 437 or 438. >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 22 September 2006 19:26 >>>>> To: Elwell, John >>>>> Cc: Cullen Jennings; SIP >>>>> Subject: Re: Rejecting connected identity (was RE: >>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>> >>>>> John, >>>>> >>>>> I want to hear what others, especially Jon and Cullen, have >>>>> to say about >>>>> this. >>>>> >>>>> It is of some concern to me that a call might fail >> because of some >>>>> problem with the identity mechanism when the same call might have >>>>> succeeded in the absence of any identity. >>>>> >>>>> But possibly the solution to this is policy in the >>>>> implementation of the >>>>> verifier. What to do in the case of the conditions that >>>> lead to these >>>>> errors could be configurable in the verifier: either to >>>> generate the >>>>> error or simply to remove the identity info from the >>>> message. And the >>>>> policy could conceivably vary based on attributes of the >>>>> message, such >>>>> as whether it is in-dialog or not. >>>>> >>>>> Does it require a change to 4474 to permit that kind of policy? >>>>> >>>>> It would be annoying if the end user had no control over the >>>>> insertion >>>>> and verification of identity, and it resulted in calls >>>>> failing that the >>>>> user would like to permit. But I suppose that is itself a policy >>>>> decision. There are certainly enterprises that want to exert >>>>> that kind >>>>> of control over what users are permitted to do. >>>>> >>>>> Paul >>>>> >>>>> Elwell, John wrote: >>>>>> Paul, >>>>>> >>>>>> I agree with most of your points, and on reflection I think >>>>> I agree that the >>>>>> solution has to be with the verifier. >>>>>> >>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>> 'Use Identity >>>>>> Header' response is concerned, because that is left to >>>>> policy, so we could >>>>>> say in connected-identity that policy should be to not send 428. >>>>>> >>>>>> However, 436, 437 and 438 responses are all a problem, >>>>> because RFC 4474 says >>>>>> that they MUST be sent under respective conditions. >>>>> Interestingly, though, >>>>>> there are other failure scenarios that can arise from the >>>>> procedures of >>>>>> section 6 of RFC 4474 for which no normative statement is >>>>> given on how to >>>>>> respond, e.g. invalid Date header field, signer not >>>>> authoritative for the >>>>>> domain. >>>>>> >>>>>> So one way to solve the present problem would be for the >>>>> connected-identity >>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>> of mid-dialog >>>>>> requests. I guess this would mean that it would update RFC >>>>> 4474 as well as >>>>>> updating RFC 3261. But I don't like this, because it seems >>>>> to remove some of >>>>>> the security properties of RFC 4474. >>>>>> >>>>>> Another way would be to accept that 436, 437 and 438 >>>>> responses will be sent, >>>>>> and failure to verify a signature will therefore result in >>>>> inability to >>>>>> process the UPDATE or re-INVITE request, and hence if the >>>> UPDATE or >>>>>> re-INVITE request was for some other purpose such as >>>>> session timer refresh >>>>>> or modifying the session, that action will fail. Then the >>>>> call will fail (in >>>>>> the case of inability to refresh the session timer) or >> the session >>>>>> modification will fail. I guess this is somewhat analogous >>>>> to caller ID >>>>>> verification failure in an INVITE request - it is >>>>> impossible to establish a >>>>>> call if verification fails. Moreover, the UAC has no >>>>> ability to rectify the >>>>>> situation, since it is at the mercy of a proxy-based >>>>> Authentication Service >>>>>> that puts a rogue Identity header field in every request. >>>>> In the connected >>>>>> identity case, the only difference is that the call is >>>>> already established >>>>>> but is likely to fail if verification fails. >>>>>> >>>>>> Of course, if the mid-dialog request is indeed from the >>>>> wrong source, then >>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>> thing to do, and >>>>>> overriding the verification procedures of RFC 4474 would >>>>> indeed be the wrong >>>>>> thing to do. So perhaps we just have to accept that these >>>>> response codes can >>>>>> be received and will lead to failure. >>>>>> >>>>>> So, my preferred way forward is simply to recommend not >>>>> sending a 428 and >>>>>> accept the consequences of other responses that the >>>>> verifier might send. >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Sent: 22 September 2006 15:13 >>>>>>> To: Elwell, John >>>>>>> Cc: Cullen Jennings; SIP >>>>>>> Subject: Re: [Sip] RE: >>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>> >>>>>>> Elwell, John wrote: >>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>> When an Update is sent. Are there any conditions under which >>>>>>>>> it might >>>>>>>>> be rejected. Bad identity for example. I think that >>>>> might need a >>>>>>>>> little discussion and also what the UA does when it sends >>>>>>> an update >>>>>>>>> with a no identity and it gets rejected. >>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>> situation where it is >>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>> purposes such as >>>>>>>> session timer refresh or session re-negotiation) just >>>>>>> because connected >>>>>>>> identity fails. >>>>>>>> My proposed fix is as follows: >>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>> with 428 'Use >>>>>>>> Identity Header'. >>>>>>> I'm not sure about this. At the least I think this one needs >>>>>>> some clear >>>>>>> explanation of the SHOULD NOT - about the conditions when >>>>> it can be >>>>>>> violated. >>>>>>> >>>>>>> I see this as somewhat analogous to doing a digest >>>> challenge on an >>>>>>> in-dialog request. In some cases it is the right thing to do. >>>>>>> >>>>>>> A UA that imposes such a requirement will be limited in what >>>>>>> it can do, >>>>>>> but that may still be right in some cases. >>>>>>> >>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>> Identity header field >>>>>>>> to a mid-dialog request if a previous request on that >>>>>>> dialog has resulted in >>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>> 438 'Invalid >>>>>>>> Identity Header'. >>>>>>> This requirement would force the authentication service to >>>>> be dialog >>>>>>> stateful, which is not ideal. Better to push the state >>>>> back into the >>>>>>> sender of the request. This may require a way for the UAC >>>>> to tell the >>>>>>> authentication service not to act. >>>>>>> >>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>> results in one of >>>>>>>> these responses if the mid-dialog request was not solely >>>>>>> for the purpose of >>>>>>>> connected identity. If solely for the purpose of connected >>>>>>> identity there is >>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>> any further >>>>>>>> action". >>>>>>> This seems wrong to me. >>>>>>> >>>>>>> I think that the remedy to these is in the verifier. The >>>>>>> purpose of the >>>>>>> verifier is ultimately to drive an authorization decision. If >>>>>>> authorization would succeed in the absence of the >>>>> identity, then the >>>>>>> request should be permitted to continue as if the identity >>>>>>> was not present. >>>>>>> >>>>>>> Unfortunately this would seem to require a revision to 4474 >>>>>>> even though >>>>>>> the paint is hardly dry on it. >>>>>>> >>>>>>> If this is done, then there is no need of a mechanism to >>>> cause the >>>>>>> authentication service *not* to authenticate. If this is >>>>> *not* done, >>>>>>> then that need remains, which will still require a >>>> change to 4474. >>>>>>> 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 >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 11:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVOH-0007hX-Sy; Thu, 05 Oct 2006 11:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVOG-0007hS-Mg for sip@ietf.org; Thu, 05 Oct 2006 11:44:04 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVOF-0004Ih-G6 for sip@ietf.org; Thu, 05 Oct 2006 11:44:04 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <20061005154400012002flk0e>; Thu, 5 Oct 2006 15:44:01 +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 k95Fi0Um001910 for ; Thu, 5 Oct 2006 11:44:00 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k95Fi0gG001906; Thu, 5 Oct 2006 11:44:00 -0400 Date: Thu, 5 Oct 2006 11:44:00 -0400 Message-Id: <200610051544.k95Fi0gG001906@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4525196F.5010103@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] Escaping rules of SIP-URI userpart References: <1ECE0EB50388174790F9694F77522CCF0D58BBC2@zrc2hxm0.corp.nortel.com> <4525196F.5010103@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > What bothers me with this thread is not that people want to use > strange characters in URIs. > > What bothers me is that people want to use it to replicate > analog telephone keypad codes, the same way it was done back then, > in SIP. It was broken then, and it is even more broken now that > addresses are supposed to be global. It's not as broken as it appears, though the reason why is subtle. Let me take as an example sipX: *91234 retrieves a call from parking orbit 1234. Because the phones don't implement this operation, it's handled by a special processor in the registrar/proxy. But that is a real URI: , and can be generated by any SIP UA in the universe. (Authorization rules restrict which UAs will be obeyed.) Any INVITE to that URI will eventually be routed to the call retrieval agent, which will effect the desired operation. In a better world, we would use a more rational URI indicator than having the first two characters of the user part be "*9", but we have to live with phones with conventional dialpads. At the other extreme, if the phone implements a feature, it is not particularly broken to have the feature be activated on a per-cal basis by pushing particular keys at the beginning of the call. What *is* broken, and what is done in analog systems, and I fear is done in some SIP systems, is to use "*-codes" to activate special features, but only when the code appears in the dial string in the signaling path between a phone and its PBX. That introduces the design error of having the meaning of a URI be dependent on its context. 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 Oct 05 11:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVUg-0002d1-AN; Thu, 05 Oct 2006 11:50:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVUe-0002cw-Ju for sip@ietf.org; Thu, 05 Oct 2006 11:50:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVUd-0005RJ-6H for sip@ietf.org; Thu, 05 Oct 2006 11:50:40 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 11:50:39 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105847209:sNHT59450572" 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 k95FocBl011910; Thu, 5 Oct 2006 11:50: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 k95FocYL004945; Thu, 5 Oct 2006 11:50:38 -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); Thu, 5 Oct 2006 11:50:38 -0400 Received: from [160.39.255.179] ([10.86.241.16]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 11:50:38 -0400 Message-ID: <452529CE.1080104@cisco.com> Date: Thu, 05 Oct 2006 11:50: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: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 15:50:38.0159 (UTC) FILETIME=[00BA5DF0:01C6E896] DKIM-Signature: a=rsa-sha1; q=dns; l=4114; t=1160063438; x=1160927438; 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]=20GRUU=20and=20Grid=20alternative |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=ojeUzTqrwCcZMwqJvDrnjnrObO2XDU70mqQwNfsOvu1Fi8aPozjSBn0NGScS2qA1I9FiIG0J 6mHeuBmj6iF/x0uzmU98xo8i45ObrSARJz3bbCB9W5Rr6y9CytFZ6eUb; 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: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Brian Stucker wrote: > I agree that proxies that don't own the targeted domain should leave the > R-URI alone (although I wouldn't bet against there being proxies out > there that tack junk onto the R-URI even though they don't own it, I > don't think we should address this case). > > Yeah, I think this can happen in cases where there may be multiple > routing steps involved in resolving the called party for a given domain. > I think you're limiting the behavior of the home proxy to a single R-URI > encoding step in resolving the final request URI, or, further, there > being only one proxy that handles "home" requests for the UAS. > > For instance the UAC may have specified an alternative address for the > UAS in the request URI, and a routing function in the middle normalized > the request URI to a preferred value. As a result, the UAC's original > R-URI may be lost. > > I think this would be a valid usecase. Right. There are many variations on this, including name to address tranlsations (like 800 numbers). My current thinking is that all of these would show up in the Route header, and the R-URI remains unchanged. For example, consider this architecture: Please view in a fixed-width font such as Courier. | | | | +--------+ | +--------+ +--------+ +--------+ | | | | | | | | | | | | 1 | | 2 | | 3 | | | UAC | ----------->| Proxy1 |--------->| Proxy2 |----->| UAS | | | | | | | | | | | | | | | | | | | +--------+ | +--------+ +--------+ +--------+ | | | | Originating | Terminating | The UAC makes a call to sip:alias@terminating.com. The original INVITE (ignoring outbound proxies) is message 1: INVITE sip:alias@terminating.com SIP/2.0 and there are no Route headers. Now, proxy 1 is owned by terminating.com, and it is responsible for providing an alias translation service like you describe. It translates alias@terminating.com to user@terminating.com, and then sees it needs to route this to proxy2 (say, via statically configured routing tables). I'd propose that the resulting INVITE (message 2) look like: INVITE sip:alias@terminating.com SIP/2.0 Route: sip:context@proxy2.terminating.com Route: sip:user@terminating.com This goes to proxy 2, which pops the top route. This top route, context@proxy2.terminating.com, indicates that this proxy is to handle it (since that proxy is proxy2), but the user part also provides it the context by whcih to interpret the request; namely, this request came from proxy1, since proxy1 was configured with this URI. This tells proxy2 that its role is to perform translation of the AOR to the registered contact. It looks at the next route and sees it has ownership for the domain there, so it performs the location service to the users contact address, sip:user@uasaddress.com. The resulting INVITE towards the UAS (message 3) looks like: INVITE sip:alias@terminating.com SIP/2.0 Route: sip:user@uasaddress.com And thus the original R-URI is preserved through the entire terminating domain. In essence, the UA loose routing concept applies to the way by which the initial request in a dialog is passed around proxies within a domain as well. I think this has numerous additional benefits. -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 Thu Oct 05 12:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVc6-00048Y-1I; Thu, 05 Oct 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 1GVVc4-000475-Cm for sip@ietf.org; Thu, 05 Oct 2006 11:58:20 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVc2-0006MW-5H for sip@ietf.org; Thu, 05 Oct 2006 11:58:20 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061005155807b11008ceice>; Thu, 5 Oct 2006 15:58:17 +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 k95Fw6Um002311 for ; Thu, 5 Oct 2006 11:58:06 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k95Fw6cg002307; Thu, 5 Oct 2006 11:58:06 -0400 Date: Thu, 5 Oct 2006 11:58:06 -0400 Message-Id: <200610051558.k95Fw6cg002307@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <45248547.9070503@lucent.com> (vkg@lucent.com) Subject: Re: [Sip] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> <005401c6e729$0fa6c1a0$0601a8c0@BEMBUSTER> <1159971838.2732.20.camel@sukothai.pingtel.com> <200610050201.k9521BPg011911@dragon.ariadne.com> <45248547.9070503@lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: sip@ietf.org X-Mailman-Version: 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: "Vijay K. Gurbani" > We might be able to reduce the number of 140's by having the proxy in > question add a (short!) parameter to the Via of the outgoing request > indicating "140 already sent for this request". Then a proxy would > not generate a 140 for a request that had this flag on a Via. This is interesting -- but if a proxy, P1, switches to TCP from UDP, and sends a 140, then chances are that all proxies downstream from P1 will use TCP as well (for the same reason that P1 did -- the request was over 1500 bytes). So, a 140 should happen only once, and not at every hop. That requires that all the proxies have the same idea what the UDP limit is (and that the request isn't modified enough to shrink at any step). That can be satisfied if all the proxies have the same idea of the path MTU. Is that a reasonable assumption? Or maybe the more reasonable assumption that *none* of the proxies know what the path MTU is, and all of them use 1500. 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 Oct 05 12:18:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVtC-0000az-4h; Thu, 05 Oct 2006 12:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVtA-0000au-TB for sip@ietf.org; Thu, 05 Oct 2006 12:16:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVt9-0000Js-DZ for sip@ietf.org; Thu, 05 Oct 2006 12:16:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2006 12:15:59 -0400 X-IronPort-AV: i="4.09,266,1157342400"; d="scan'208"; a="105851004:sNHT60045120" 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 k95GFxsh023513; Thu, 5 Oct 2006 12:15:59 -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 k95GFxYJ019920; Thu, 5 Oct 2006 12:15:59 -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, 5 Oct 2006 12:15:58 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 12:15:58 -0400 Message-ID: <45252FBD.4030602@cisco.com> Date: Thu, 05 Oct 2006 12:15:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> <45240A5B.3000103@cisco.com> In-Reply-To: <45240A5B.3000103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 16:15:58.0714 (UTC) FILETIME=[8B0CA5A0:01C6E899] DKIM-Signature: a=rsa-sha1; q=dns; l=5797; t=1160064959; x=1160928959; 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=20Grid=20alternative |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3D37wdfzTcXxsKFn2cKwMMZsWTSx8=3D; b=SrIXnlbK2nQwJvBBuST0CCc7+hrIPpwmn9UfdDT27mkDgvyoTncaePFToEknefza0TjF+FZR yVsFEreEzJtQwhhszab+AFi9Br/nArvrH8BDnHt/cpTuELDqD983BvBA; 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: 2086112c730e13d5955355df27e3074b Cc: IETF SIP List , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Unfortunately, I don't think this eliminates the need for P-Called-Party-ID in IMS. In IMS, when the AOR in the R-URI is translated to a contact address in the R-URI, a P-Called-Party-ID header is added containing that AOR. Later, a downstream proxy (the terminating P-CSCF) remembers this value when forwarding the request to the UAS. Then when the response comes back from the UAS, that proxy adds a P-Asserted-Identity header using the value from the P-Called-Party-ID header of the request. In this way, the identity of the called party is asserted. Until now, plans to carry gruu into IMS have proposed that when a gruu is translated, the P-Called-Party-ID header should be set to the AOR, not the gruu. While we have lots of identity work in process that addresses similar issues in different ways. But meanwhile that is what IMS does. It depends on P-Called-Party-ID containing something suitable for use as an identity, suitable for authorization decisions, etc. To make this work with gruu, until now plans to carry gruu into IMS have proposed that when a gruu is translated, the P-Called-Party-ID header should be set to the AOR, not the gruu. If loose routing of the contact is adopted, and the P-Called-Party-ID usage is eliminated, then the identity of the called party would have to be inferred from the R-URI. For instance in this case if the callee was identified by an assigned anonymous gruu, then the identity coming back would have that, which wouldn't be very useful. At the moment, I expect that IMS may well continue to need P-Called-Party-ID even after this change. That of course is subject to further consideration, but lets not count our benefits until they have been confirmed. Paul Jonathan Rosenberg wrote: > I don't follow. The only P-header issue this solves is > P-Called-Party-ID. That header was added to deal exactly with this issue > of the r-uri being rewritten, so the UAS doesn't know which public > identity was targeted by the request. By not rewriting the request URI > that problem is eliminated. > > What trust-domain issues are you referring to? > > -Jonathan R. > > Brian Stucker wrote: > >> I believe what you are describing here is essentially extending the >> routing mechanism used within the IMS core network to route messages >> between various servers (x-CSCFs, BGCFs, App Servers, etc). >> Although this may help with a number of issues, and on the face of it is >> a relatively simple idea (use a separate stack data structure for >> routing instead of a static URI) I don't think it solves all the >> problems you may think it does. >> >> For instance, existing P-headers also have a trust-domain and network >> assertion factor associated with them. >> >> Regards, >> Brian >> >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wednesday, >>> September 27, 2006 12:50 AM >>> To: IETF SIP List >>> Subject: [Sip] GRUU and Grid alternative >>> >>> During our call on GRUU last week, there was a discussion on this >>> issue that ekr raised, where he would like to see the grid usable >>> outside of just gruu, i.e., with any AOR. >>> >>> During the call, I made a suggestion for an alternative solution, and >>> there was agreement amongst those on the call for the proposed approach. >>> >>> The basic idea would be to remove the grid mechanism entirely from >>> the gruu draft. Instead, a separate specification would be developed >>> which would allow for loose routing to apply to user agents. So, >>> consider a UA which registers. It would include a contact and a >>> Supported header field with the value "ua-route". The registrar, >>> assuming it understands this, notes that the UA supports UA loose >>> routing and stores the contact. When an incoming call arrives for the >>> AOR, rather than rewriting the R-URI with the registered contact, it >>> pushes the registered contact into a Route header and leaves the >>> R-URI alone (assuming the registered UA supports this mechanism). >>> >>> How does this solve the grid problem? Lets say my AOR is >>> sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some arbitrary >>> parameter, say sip:jdrosen@cisco.com;foo=baz, and hand it out to some >>> correspondent. When a correspondent sends a request to that URI, it >>> arrives at my home proxy. From there, since the R-URI is NOT >>> rewritten, the entire URI, parameters and all, is passed to the UA. >>> Thus, the UA knows the URI that was de-referenced. We wouldn't >>> necessarily have to standardize a specific URI parameter, like grid, >>> to carry the opaque data. >>> >>> This trick solves a whole bunch of other problems too. It would >>> eliminate the need for the IMS P-Called-Party-ID header field, and it >>> would help clarify when a request is retargeted (change in R-URI) vs. >>> when its just being delivered to the recipient (no change in R-URI). >>> >>> 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 Thu Oct 05 12:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWUe-0004so-UI; Thu, 05 Oct 2006 12:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVWUd-0004s6-1a for sip@ietf.org; Thu, 05 Oct 2006 12:54:43 -0400 Received: from chekov.siemens.com.br ([200.186.153.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVWUY-0007Qn-CN for sip@ietf.org; Thu, 05 Oct 2006 12:54:43 -0400 Received: from sao0021x.siemens.com.br (sao0021x [129.214.16.91]) by chekov.siemens.com.br (Postfix) with ESMTP id C727038940A for ; Thu, 5 Oct 2006 13:54:36 -0300 (BRT) Received: from sao0021x.siemens.com.br (localhost [127.0.0.1]) by localhost.siemens.com.br (Postfix) with ESMTP id D48E933311 for ; Thu, 5 Oct 2006 13:53:32 -0300 (BRT) Received: from sao1100a.ww101.siemens.net (sao1100a.siemens.com.br [129.214.31.218]) by sao0021x.siemens.com.br (Postfix) with ESMTP id BF94E613DA for ; Thu, 5 Oct 2006 13:53:32 -0300 (BRT) Received: from SAO1014V.ww101.siemens.net ([129.214.31.14]) by sao1100a.ww101.siemens.net with InterScan Messaging Security Suite; Thu, 05 Oct 2006 13:54:35 -0300 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Oct 2006 13:54:35 -0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Non-chargeable indication for B-Party in SIP calls Thread-Index: Acbonu/ck3OwrnHPS2WCk0TVOizw8Q== From: "Uemura, Marcelo Takashi" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [Sip] Non-chargeable indication for B-Party in SIP calls X-BeenThere: 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="===============0263346160==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0263346160== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E89E.EFCF66B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E89E.EFCF66B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello SIP fans, =20 Is there any draft or proposal within SIP to indicate that B-Party is non-chargeable (like what is indicated in BCI of ISUP signaling)? Sometimes this is necessary for applications like pre-paid servers, which could not charge this type of calls. =20 Looking for answers... =20 Regards, =20 Marcelo Takashi Uemura =20 =20 ------_=_NextPart_001_01C6E89E.EFCF66B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello SIP fans,

 

Is there any draft or proposal within SIP to indicate = that B-Party is non-chargeable (like what is indicated in BCI of ISUP = signaling)? Sometimes this is necessary for applications like pre-paid servers, which could = not charge this type of calls.

 

Looking for = answers…

 

Regards,

 

Marcelo Takashi = Uemura

 

 

------_=_NextPart_001_01C6E89E.EFCF66B7-- --===============0263346160== 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 --===============0263346160==-- From sip-bounces@ietf.org Thu Oct 05 14:30:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXw2-0008BZ-06; Thu, 05 Oct 2006 14:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVXw0-0008BG-MN for sip@ietf.org; Thu, 05 Oct 2006 14:27:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVXvy-0007Cx-4K for sip@ietf.org; Thu, 05 Oct 2006 14:27:04 -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 k95IQng06669; Thu, 5 Oct 2006 14:26: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] GRUU and Grid alternative Date: Thu, 5 Oct 2006 13:26:49 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110CAFA4C@zrc2hxm2.corp.nortel.com> In-Reply-To: <45252FBD.4030602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: AcbomZIiTkAZ+Pn8QLCCCV6EFkVClAAEVBPw From: "Brian Stucker" To: "Paul Kyzivat" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 agree with your assessment Paul. There are definitely cases in 23.228 that use the P-Called-Party-ID header to later create a P-Asserted-ID header. The reason I bring it up was two-fold: as you say, it we may be counting chickens too early, and because if we are counting on similar properties of the R-URI behavior in the proposed mechanism (which I think is an interesting proposal) for non-3GPP related problems, those chickens may be in jeopardy as well. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, October 05, 2006 11:16 AM > To: Jonathan Rosenberg > Cc: Stucker, Brian (RICH1:AR00); IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 > Unfortunately, I don't think this eliminates the need for=20 > P-Called-Party-ID in IMS. >=20 > In IMS, when the AOR in the R-URI is translated to a contact=20 > address in the R-URI, a P-Called-Party-ID header is added=20 > containing that AOR.=20 > Later, a downstream proxy (the terminating P-CSCF) remembers=20 > this value when forwarding the request to the UAS. Then when=20 > the response comes back from the UAS, that proxy adds a=20 > P-Asserted-Identity header using the value from the=20 > P-Called-Party-ID header of the request. In this way, the=20 > identity of the called party is asserted. Until now, plans to=20 > carry gruu into IMS have proposed that when a gruu is=20 > translated, the P-Called-Party-ID header should be set to the=20 > AOR, not the gruu. >=20 > While we have lots of identity work in process that addresses=20 > similar issues in different ways. But meanwhile that is what IMS does. >=20 > It depends on P-Called-Party-ID containing something suitable=20 > for use as an identity, suitable for authorization decisions,=20 > etc. To make this work with gruu, until now plans to carry=20 > gruu into IMS have proposed that when a gruu is translated,=20 > the P-Called-Party-ID header should be set to the AOR, not the gruu. >=20 > If loose routing of the contact is adopted, and the=20 > P-Called-Party-ID usage is eliminated, then the identity of=20 > the called party would have to be inferred from the R-URI.=20 > For instance in this case if the callee was identified by an=20 > assigned anonymous gruu, then the identity coming back would=20 > have that, which wouldn't be very useful. >=20 > At the moment, I expect that IMS may well continue to need=20 > P-Called-Party-ID even after this change. That of course is=20 > subject to further consideration, but lets not count our=20 > benefits until they have been confirmed. >=20 > Paul >=20 > Jonathan Rosenberg wrote: > > I don't follow. The only P-header issue this solves is=20 > > P-Called-Party-ID. That header was added to deal exactly with this=20 > > issue of the r-uri being rewritten, so the UAS doesn't know which=20 > > public identity was targeted by the request. By not rewriting the=20 > > request URI that problem is eliminated. > >=20 > > What trust-domain issues are you referring to? > >=20 > > -Jonathan R. > >=20 > > Brian Stucker wrote: > >=20 > >> I believe what you are describing here is essentially=20 > extending the=20 > >> routing mechanism used within the IMS core network to=20 > route messages=20 > >> between various servers (x-CSCFs, BGCFs, App Servers, etc). > >> Although this may help with a number of issues, and on the=20 > face of it=20 > >> is a relatively simple idea (use a separate stack data=20 > structure for=20 > >> routing instead of a static URI) I don't think it solves all the=20 > >> problems you may think it does. > >> > >> For instance, existing P-headers also have a trust-domain=20 > and network=20 > >> assertion factor associated with them. > >> > >> Regards, > >> Brian > >> > >> > >>> -----Original Message----- > >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent:=20 > Wednesday,=20 > >>> September 27, 2006 12:50 AM > >>> To: IETF SIP List > >>> Subject: [Sip] GRUU and Grid alternative > >>> > >>> During our call on GRUU last week, there was a discussion on this=20 > >>> issue that ekr raised, where he would like to see the grid usable=20 > >>> outside of just gruu, i.e., with any AOR. > >>> > >>> During the call, I made a suggestion for an alternative solution,=20 > >>> and there was agreement amongst those on the call for the=20 > proposed approach. > >>> > >>> The basic idea would be to remove the grid mechanism=20 > entirely from=20 > >>> the gruu draft. Instead, a separate specification would=20 > be developed=20 > >>> which would allow for loose routing to apply to user agents. So,=20 > >>> consider a UA which registers. It would include a contact and a=20 > >>> Supported header field with the value "ua-route". The registrar,=20 > >>> assuming it understands this, notes that the UA supports UA loose=20 > >>> routing and stores the contact. When an incoming call arrives for=20 > >>> the AOR, rather than rewriting the R-URI with the registered=20 > >>> contact, it pushes the registered contact into a Route header and=20 > >>> leaves the R-URI alone (assuming the registered UA=20 > supports this mechanism). > >>> > >>> How does this solve the grid problem? Lets say my AOR is=20 > >>> sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some=20 > >>> arbitrary parameter, say sip:jdrosen@cisco.com;foo=3Dbaz,=20 > and hand it=20 > >>> out to some correspondent. When a correspondent sends a=20 > request to=20 > >>> that URI, it arrives at my home proxy. From there, since=20 > the R-URI=20 > >>> is NOT rewritten, the entire URI, parameters and all, is=20 > passed to the UA. > >>> Thus, the UA knows the URI that was de-referenced. We wouldn't=20 > >>> necessarily have to standardize a specific URI parameter,=20 > like grid,=20 > >>> to carry the opaque data. > >>> > >>> This trick solves a whole bunch of other problems too. It would=20 > >>> eliminate the need for the IMS P-Called-Party-ID header=20 > field, and=20 > >>> it would help clarify when a request is retargeted=20 > (change in R-URI) vs. > >>> when its just being delivered to the recipient (no change=20 > in R-URI). > >>> > >>> Comments? > >>> > >>> -Jonathan R. > >>> > >>> > >>> --=20 > >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>> Cisco Fellow =20 > Parsippany, NJ 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 > >>> > >> > >> > >=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 Oct 05 14:45:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYBa-0001EU-4m; Thu, 05 Oct 2006 14:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYBX-0001EO-Ru for sip@ietf.org; Thu, 05 Oct 2006 14:43:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYBW-0004H2-C2 for sip@ietf.org; Thu, 05 Oct 2006 14:43:07 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 11:43:05 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="328485515:sNHT56342412" 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 k95Ih499005839; Thu, 5 Oct 2006 11:43:04 -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 k95IgnP1009641; Thu, 5 Oct 2006 11:43:04 -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, 5 Oct 2006 14:43:03 -0400 Received: from [160.39.252.102] ([10.86.240.209]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:43:02 -0400 Message-ID: <45255236.6060907@cisco.com> Date: Thu, 05 Oct 2006 14:43: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: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF69@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF69@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 18:43:03.0060 (UTC) FILETIME=[16C4FD40:01C6E8AE] DKIM-Signature: a=rsa-sha1; q=dns; l=3585; t=1160073784; x=1160937784; 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]=20GRUU=20and=20Grid=20alternative; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=FTp+WHo0vf/Ukk3Ywci9w0hqbauJahtlUF54PgzDkoKXXXB00jq4WSV17keIN42OQWQZMCGo D6CUMW6UNO4h717gn3bZFEuU0cuEXufzd+wVGb25xsVSHj85si9ePvCZ; 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: 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 Brian Stucker wrote: > Looking at RFC-3455, and how the P-Called-Party-ID header is defined, > there are some implications that weren't represented in the approach > below that I think we should consider. > > For instance, Section 6.2 of RFC-3455 brings up a good point about the > security and privacy issues around using the P-Called-Party-ID header. > If the proposed mechanism is used to obviate the need for this header, > or otherwise used to mimic the header's purpose we would have to address > those concerns. OK, lets take a look. Here is the contents of that section: 6.2 P-Called-Party-ID Due to the nature of the P-Called-Party-ID header, this header does not introduce any significant security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment. An eavesdropper may collect the list of identities a user is registered. This may have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. The second paragraph is the only one that raises an issue. The issue actually has nothing to do with p-called-party-id. If you are worried about knowing what identities a user was registered under, you need only snoop the REGISTER message. The security mitigation for this is to protect the SIP signaling path using sips or TLS, which would protect the REGISTER, and of course INVITE towards the UAS. That would hide the p-called-party-id and request-URI from eavesdroppers. So I don't see any issue here. > > Further, Section 4.2.2.1 states that the UAC MUST NOT insert a > P-Called-Party-ID header field in any SIP request. This is because this > it would potentially violate the transitive trust statement of > applicability given in Section 1 of RFC-3455. I believe, by relying on > the value of the R-URI specified by the UAC if this mechanism replaces > the P-Called-Party-ID header, we'd be violating the spirit of Section > 4.2.2.1 of RFC-3455. I disagree. In fact, the requirement of not inserting is an artifact of the fact that it IS a separate header. If you use the R-URI the security issue goes away. The security concern is that if the UE has special treatment for an incoming call based on the called party ID (for example, special ringtones), the caller can insert this value in P-Called-Party-ID while using a different value in the R-URI. If the P-Called-Party-ID is passed to the UE, it can result in the wrong behavior. Of course, you wouldn't have this problem in the first place if the called party ID were present only in the request-URI, per my proposal. The security problem happens because the called party ID is present in TWO places (the R-URI up to the terminating proxy, and the called-party ID after it), and thus they can be inconsistent. If there is only one place, there is no chance of consistency problems. Consequently, I see the UA loose routing mechanism only improving upon the security issue with P-Called-Party-ID. -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 Thu Oct 05 14:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYHh-0004lB-Ai; Thu, 05 Oct 2006 14:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYHf-0004kP-9f for sip@ietf.org; Thu, 05 Oct 2006 14:49:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYHd-000638-Km for sip@ietf.org; Thu, 05 Oct 2006 14:49:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2006 11:49:25 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="44996668:sNHT64219740" 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 k95InOMH005275; Thu, 5 Oct 2006 14:49:24 -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 k95InJYT011655; Thu, 5 Oct 2006 14:49:24 -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, 5 Oct 2006 14:49:24 -0400 Received: from [160.39.252.102] ([10.86.240.209]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 14:49:23 -0400 Message-ID: <452553B3.4030106@cisco.com> Date: Thu, 05 Oct 2006 14:49: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: Paul Kyzivat Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> <45240A5B.3000103@cisco.com> <45252FBD.4030602@cisco.com> In-Reply-To: <45252FBD.4030602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 18:49:23.0944 (UTC) FILETIME=[F9CB4680:01C6E8AE] DKIM-Signature: a=rsa-sha1; q=dns; l=6879; t=1160074164; x=1160938164; 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]=20GRUU=20and=20Grid=20alternative |To:Paul=20Kyzivat=20; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=r0ruMMHvng/DRU5PFnFW1uOKX7+o72XbBniVc/sSR9Jo2ioKWmXhmAjtWaivw/6QgcVSt0Xv c6GR21q65Baaui1ynkttmKKDfsmp0X5L0dAr97O3/r4b5X2N7D24vEmK; 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: c54bc2f42d02429833c0ca4b8725abd7 Cc: IETF SIP List , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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 good point; thanks Paul. I think there is a deeper question here about whether the calling party has a right to know the called party identity beyond the information revealed by the GRUU. If the GRUU is anonymous, the caller only has the anonymous URI, and presumably this is because the called party wanted to remain anonymous. Should then the P-CSCF provide the actual called party identity to the caller after the call completes? I would think this is a bad thing and a violation of privacy, no? -Jonathan R. Paul Kyzivat wrote: > Unfortunately, I don't think this eliminates the need for > P-Called-Party-ID in IMS. > > In IMS, when the AOR in the R-URI is translated to a contact address in > the R-URI, a P-Called-Party-ID header is added containing that AOR. > Later, a downstream proxy (the terminating P-CSCF) remembers this value > when forwarding the request to the UAS. Then when the response comes > back from the UAS, that proxy adds a P-Asserted-Identity header using > the value from the P-Called-Party-ID header of the request. In this way, > the identity of the called party is asserted. Until now, plans to carry > gruu into IMS have proposed that when a gruu is translated, the > P-Called-Party-ID header should be set to the AOR, not the gruu. > > While we have lots of identity work in process that addresses similar > issues in different ways. But meanwhile that is what IMS does. > > It depends on P-Called-Party-ID containing something suitable for use as > an identity, suitable for authorization decisions, etc. To make this > work with gruu, until now plans to carry gruu into IMS have proposed > that when a gruu is translated, the P-Called-Party-ID header should be > set to the AOR, not the gruu. > > If loose routing of the contact is adopted, and the P-Called-Party-ID > usage is eliminated, then the identity of the called party would have to > be inferred from the R-URI. For instance in this case if the callee was > identified by an assigned anonymous gruu, then the identity coming back > would have that, which wouldn't be very useful. > > At the moment, I expect that IMS may well continue to need > P-Called-Party-ID even after this change. That of course is subject to > further consideration, but lets not count our benefits until they have > been confirmed. > > Paul > > Jonathan Rosenberg wrote: > >> I don't follow. The only P-header issue this solves is >> P-Called-Party-ID. That header was added to deal exactly with this >> issue of the r-uri being rewritten, so the UAS doesn't know which >> public identity was targeted by the request. By not rewriting the >> request URI that problem is eliminated. >> >> What trust-domain issues are you referring to? >> >> -Jonathan R. >> >> Brian Stucker wrote: >> >>> I believe what you are describing here is essentially extending the >>> routing mechanism used within the IMS core network to route messages >>> between various servers (x-CSCFs, BGCFs, App Servers, etc). >>> Although this may help with a number of issues, and on the face of it is >>> a relatively simple idea (use a separate stack data structure for >>> routing instead of a static URI) I don't think it solves all the >>> problems you may think it does. >>> >>> For instance, existing P-headers also have a trust-domain and network >>> assertion factor associated with them. >>> >>> Regards, >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wednesday, >>>> September 27, 2006 12:50 AM >>>> To: IETF SIP List >>>> Subject: [Sip] GRUU and Grid alternative >>>> >>>> During our call on GRUU last week, there was a discussion on this >>>> issue that ekr raised, where he would like to see the grid usable >>>> outside of just gruu, i.e., with any AOR. >>>> >>>> During the call, I made a suggestion for an alternative solution, >>>> and there was agreement amongst those on the call for the proposed >>>> approach. >>>> >>>> The basic idea would be to remove the grid mechanism entirely from >>>> the gruu draft. Instead, a separate specification would be developed >>>> which would allow for loose routing to apply to user agents. So, >>>> consider a UA which registers. It would include a contact and a >>>> Supported header field with the value "ua-route". The registrar, >>>> assuming it understands this, notes that the UA supports UA loose >>>> routing and stores the contact. When an incoming call arrives for >>>> the AOR, rather than rewriting the R-URI with the registered >>>> contact, it pushes the registered contact into a Route header and >>>> leaves the R-URI alone (assuming the registered UA supports this >>>> mechanism). >>>> >>>> How does this solve the grid problem? Lets say my AOR is >>>> sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some >>>> arbitrary parameter, say sip:jdrosen@cisco.com;foo=baz, and hand it >>>> out to some correspondent. When a correspondent sends a request to >>>> that URI, it arrives at my home proxy. From there, since the R-URI >>>> is NOT rewritten, the entire URI, parameters and all, is passed to >>>> the UA. Thus, the UA knows the URI that was de-referenced. We >>>> wouldn't necessarily have to standardize a specific URI parameter, >>>> like grid, to carry the opaque data. >>>> >>>> This trick solves a whole bunch of other problems too. It would >>>> eliminate the need for the IMS P-Called-Party-ID header field, and >>>> it would help clarify when a request is retargeted (change in R-URI) >>>> vs. when its just being delivered to the recipient (no change in >>>> R-URI). >>>> >>>> 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 Thu Oct 05 15:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYha-0001xQ-SJ; Thu, 05 Oct 2006 15:16:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYhZ-0001xK-9z for sip@ietf.org; Thu, 05 Oct 2006 15:16:13 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYhX-0003NC-Rn for sip@ietf.org; Thu, 05 Oct 2006 15:16:13 -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 k95J9VU18330; Thu, 5 Oct 2006 15:09:31 -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] GRUU and Grid alternative Date: Thu, 5 Oct 2006 14:16:01 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110CAFB4A@zrc2hxm2.corp.nortel.com> In-Reply-To: <45255236.6060907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: AcborlaCefxFGTUURJW2Sk8L2R63MgAAo9Lg From: "Brian Stucker" To: "Jonathan Rosenberg" 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 I think you may want to look at what the header gets used for in the 24.229 procedures. It gets used to populate values that definitely do have a trust domain context associated with them. I didn't want to get into the guts of discussing a 3GPP document on an IETF list in the earlier email. Re Section 4.2.2.1:=20 I don't think it has anything to do with the fact that it's two headers or not, you want to know that the value that's there is correct. If I understand the proposal correctly, you're also using two headers: route and R-URI. So if you feel that having two headers really is the issue here, then what's the difference? Re Section 6.2: In a general sense, can't I make the R-URI say anything I want by doing the following: INVITE sip:anything-i-want@domain SIP/2.0 Route: When the next hop gets this, it's going to ignore the R-URI, route on the Route header, and not change the R-URI. It's just a matter of knowing how many hops you may need to cover with loose-route route headers to get past the point you want to get past with the bogus R-URI header. It's not necessarily going to interfere with your session setup, as per the first paragraph of Section 6.2, but it doesn't mean that the value is correct either. Regards, Brian=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, October 05, 2006 1:43 PM > To: Stucker, Brian (RICH1:AR00) > Cc: IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 >=20 >=20 > Brian Stucker wrote: >=20 > > Looking at RFC-3455, and how the P-Called-Party-ID header=20 > is defined,=20 > > there are some implications that weren't represented in the=20 > approach=20 > > below that I think we should consider. > >=20 > > For instance, Section 6.2 of RFC-3455 brings up a good=20 > point about the=20 > > security and privacy issues around using the=20 > P-Called-Party-ID header. > > If the proposed mechanism is used to obviate the need for=20 > this header,=20 > > or otherwise used to mimic the header's purpose we would have to=20 > > address those concerns. >=20 > OK, lets take a look. Here is the contents of that section: >=20 > 6.2 P-Called-Party-ID >=20 > Due to the nature of the P-Called-Party-ID header, this=20 > header does > not introduce any significant security concern. It is=20 > possible for > an attacker to modify the contents of the header. However, this > modification will not cause any harm to the session establishment. >=20 > An eavesdropper may collect the list of identities a user is > registered. This may have privacy implications. To mitigate this > problem, this extension SHOULD only be used in a secured=20 > environment, > where encryption of SIP messages is provided either end-to-end or > hop-by-hop. >=20 >=20 > The second paragraph is the only one that raises an issue.=20 > The issue actually has nothing to do with p-called-party-id.=20 > If you are worried about knowing what identities a user was=20 > registered under, you need only snoop the REGISTER message.=20 > The security mitigation for this is to protect the SIP=20 > signaling path using sips or TLS, which would protect the=20 > REGISTER, and of course INVITE towards the UAS. That would=20 > hide the p-called-party-id and request-URI from eavesdroppers. >=20 > So I don't see any issue here. >=20 > >=20 > > Further, Section 4.2.2.1 states that the UAC MUST NOT insert a=20 > > P-Called-Party-ID header field in any SIP request. This is because=20 > > this it would potentially violate the transitive trust statement of=20 > > applicability given in Section 1 of RFC-3455. I believe,=20 > by relying=20 > > on the value of the R-URI specified by the UAC if this mechanism=20 > > replaces the P-Called-Party-ID header, we'd be violating=20 > the spirit of=20 > > Section > > 4.2.2.1 of RFC-3455. >=20 > I disagree. In fact, the requirement of not inserting is an=20 > artifact of the fact that it IS a separate header. If you use=20 > the R-URI the security issue goes away. >=20 > The security concern is that if the UE has special treatment=20 > for an incoming call based on the called party ID (for=20 > example, special ringtones), the caller can insert this value=20 > in P-Called-Party-ID while using a different value in the=20 > R-URI. If the P-Called-Party-ID is passed to the UE, it can=20 > result in the wrong behavior. >=20 > Of course, you wouldn't have this problem in the first place=20 > if the called party ID were present only in the request-URI,=20 > per my proposal.=20 > The security problem happens because the called party ID is=20 > present in TWO places (the R-URI up to the terminating proxy,=20 > and the called-party ID after it), and thus they can be=20 > inconsistent. If there is only one place, there is no chance=20 > of consistency problems. >=20 > Consequently, I see the UA loose routing mechanism only=20 > improving upon the security issue with P-Called-Party-ID. >=20 > -Jonathan R. >=20 >=20 > --=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=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 Oct 05 16:28:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZnA-0005Om-Jn; Thu, 05 Oct 2006 16:26:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZn9-0005OX-2L for sip@ietf.org; Thu, 05 Oct 2006 16:26:03 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVZn6-0008NZ-MS for sip@ietf.org; Thu, 05 Oct 2006 16:26:03 -0400 Received: by tutpro.com (Postfix, from userid 65534) id D7DF713F8A8; Thu, 5 Oct 2006 23:25:45 +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 (nuclease164.gprs.dnafinland.fi [62.78.108.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 17F0913F8A3; Thu, 5 Oct 2006 23:25:35 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3A668F0258; Thu, 5 Oct 2006 23:26:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17701.27248.192068.881081@rautu.tutpro.com> Date: Thu, 5 Oct 2006 23:26:24 +0300 From: Juha Heinanen To: Jonathan Rosenberg Subject: Re: [Sip] GRUU and Grid alternative In-Reply-To: <452529CE.1080104@cisco.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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, many sip phones on the market use as host part of r-uri their own domain. for example, if a phone in domain foo.bar makes call to local number 2345657, the phone will send out r-uri sip:234567@foo.bar. when that request hits foo.bar's proxy, it usually canonized the number that, for example, results in r-uri sip:+35640234567@foo.bar. then the proxy may make an enum query and find out that the r-uri needs to be re-written as sip:jh@tutpro.com. the proxy then re-writes r-uri accordingly and sends the request to tutpro.com's proxy. my question is, are you suggesting that when the request hit's tutpro.com's proxy, its request uri is still sip:234567@foo.bar and that route header contains sip:jh@tutpro.com? if so, what is the difference between r-uri and to uri? why do we need both? -- 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 Oct 05 17:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb10-0007tL-Rg; Thu, 05 Oct 2006 17:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb0y-0007pn-KG for sip@ietf.org; Thu, 05 Oct 2006 17:44:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVawG-0002Yf-9s for sip@ietf.org; Thu, 05 Oct 2006 17:39:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2006 14:39:17 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="45015409:sNHT132459408" 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 k95LcrlD024835; Thu, 5 Oct 2006 17:38: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 k95LcrDM002347; Thu, 5 Oct 2006 17:38:53 -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, 5 Oct 2006 17:38:52 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Oct 2006 17:38:52 -0400 Message-ID: <45257B6C.6090907@cisco.com> Date: Thu, 05 Oct 2006 17:38:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CC92@zrc2hxm2.corp.nortel.com> <45240A5B.3000103@cisco.com> <45252FBD.4030602@cisco.com> <452553B3.4030106@cisco.com> In-Reply-To: <452553B3.4030106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2006 21:38:52.0819 (UTC) FILETIME=[A6EA7630:01C6E8C6] DKIM-Signature: a=rsa-sha1; q=dns; l=7581; t=1160084333; x=1160948333; 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=20Grid=20alternative |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3D37wdfzTcXxsKFn2cKwMMZsWTSx8=3D; b=VNdFVkOyEVh2AXssQPIcOpGrQVip/3Lri1ATQWTIPaoZsbsZKK3XjNkwuEA5HrhtzAtPelTm 7IY5sYsl7IryssWniFQFpGJVUl5igc9DIQMWVuH7aBsEwEoQuk5gG/Rg; 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: 20f22c03b5c66958bff5ef54fcda6e48 Cc: IETF SIP List , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > This is a good point; thanks Paul. > > I think there is a deeper question here about whether the calling party > has a right to know the called party identity beyond the information > revealed by the GRUU. If the GRUU is anonymous, the caller only has the > anonymous URI, and presumably this is because the called party wanted to > remain anonymous. Should then the P-CSCF provide the actual called party > identity to the caller after the call completes? I would think this is a > bad thing and a violation of privacy, no? Well, the P-Asserted-Identity in the response is largely there for use by servers in the trust domain. It can be removed before it exits the trust domain, so that it isn't made available to the caller, if desired. But I don't think that is currently done, and in fact may negate some of the intent of the feature. Typically it would only be removed in the forward direction based on the Privacy:id header. I don't think id privacy in the reverse direction is supported, though perhaps it could be. That might be the proper answer in this case. It is a bit of a fuzzy area wrt the details of IMS, and in large part is probably not an issue for ietf. Presumably IMS can continue to use P-Called-Party-ID if they want to. And *maybe* they will find that it is no longer needed. We just don't know yet. Paul > -Jonathan R. > > Paul Kyzivat wrote: >> Unfortunately, I don't think this eliminates the need for >> P-Called-Party-ID in IMS. >> >> In IMS, when the AOR in the R-URI is translated to a contact address >> in the R-URI, a P-Called-Party-ID header is added containing that AOR. >> Later, a downstream proxy (the terminating P-CSCF) remembers this >> value when forwarding the request to the UAS. Then when the response >> comes back from the UAS, that proxy adds a P-Asserted-Identity header >> using the value from the P-Called-Party-ID header of the request. In >> this way, the identity of the called party is asserted. Until now, >> plans to carry gruu into IMS have proposed that when a gruu is >> translated, the P-Called-Party-ID header should be set to the AOR, not >> the gruu. >> >> While we have lots of identity work in process that addresses similar >> issues in different ways. But meanwhile that is what IMS does. >> >> It depends on P-Called-Party-ID containing something suitable for use >> as an identity, suitable for authorization decisions, etc. To make >> this work with gruu, until now plans to carry gruu into IMS have >> proposed that when a gruu is translated, the P-Called-Party-ID header >> should be set to the AOR, not the gruu. >> >> If loose routing of the contact is adopted, and the P-Called-Party-ID >> usage is eliminated, then the identity of the called party would have >> to be inferred from the R-URI. For instance in this case if the callee >> was identified by an assigned anonymous gruu, then the identity coming >> back would have that, which wouldn't be very useful. >> >> At the moment, I expect that IMS may well continue to need >> P-Called-Party-ID even after this change. That of course is subject to >> further consideration, but lets not count our benefits until they have >> been confirmed. >> >> Paul >> >> Jonathan Rosenberg wrote: >> >>> I don't follow. The only P-header issue this solves is >>> P-Called-Party-ID. That header was added to deal exactly with this >>> issue of the r-uri being rewritten, so the UAS doesn't know which >>> public identity was targeted by the request. By not rewriting the >>> request URI that problem is eliminated. >>> >>> What trust-domain issues are you referring to? >>> >>> -Jonathan R. >>> >>> Brian Stucker wrote: >>> >>>> I believe what you are describing here is essentially extending the >>>> routing mechanism used within the IMS core network to route messages >>>> between various servers (x-CSCFs, BGCFs, App Servers, etc). >>>> Although this may help with a number of issues, and on the face of >>>> it is >>>> a relatively simple idea (use a separate stack data structure for >>>> routing instead of a static URI) I don't think it solves all the >>>> problems you may think it does. >>>> >>>> For instance, existing P-headers also have a trust-domain and network >>>> assertion factor associated with them. >>>> >>>> Regards, >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: >>>>> Wednesday, September 27, 2006 12:50 AM >>>>> To: IETF SIP List >>>>> Subject: [Sip] GRUU and Grid alternative >>>>> >>>>> During our call on GRUU last week, there was a discussion on this >>>>> issue that ekr raised, where he would like to see the grid usable >>>>> outside of just gruu, i.e., with any AOR. >>>>> >>>>> During the call, I made a suggestion for an alternative solution, >>>>> and there was agreement amongst those on the call for the proposed >>>>> approach. >>>>> >>>>> The basic idea would be to remove the grid mechanism entirely from >>>>> the gruu draft. Instead, a separate specification would be >>>>> developed which would allow for loose routing to apply to user >>>>> agents. So, consider a UA which registers. It would include a >>>>> contact and a Supported header field with the value "ua-route". The >>>>> registrar, assuming it understands this, notes that the UA supports >>>>> UA loose routing and stores the contact. When an incoming call >>>>> arrives for the AOR, rather than rewriting the R-URI with the >>>>> registered contact, it pushes the registered contact into a Route >>>>> header and leaves the R-URI alone (assuming the registered UA >>>>> supports this mechanism). >>>>> >>>>> How does this solve the grid problem? Lets say my AOR is >>>>> sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some >>>>> arbitrary parameter, say sip:jdrosen@cisco.com;foo=baz, and hand it >>>>> out to some correspondent. When a correspondent sends a request to >>>>> that URI, it arrives at my home proxy. From there, since the R-URI >>>>> is NOT rewritten, the entire URI, parameters and all, is passed to >>>>> the UA. Thus, the UA knows the URI that was de-referenced. We >>>>> wouldn't necessarily have to standardize a specific URI parameter, >>>>> like grid, to carry the opaque data. >>>>> >>>>> This trick solves a whole bunch of other problems too. It would >>>>> eliminate the need for the IMS P-Called-Party-ID header field, and >>>>> it would help clarify when a request is retargeted (change in >>>>> R-URI) vs. when its just being delivered to the recipient (no >>>>> change in R-URI). >>>>> >>>>> 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 Thu Oct 05 17:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb2l-0001bX-Mk; Thu, 05 Oct 2006 17:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVb2k-0001bO-78 for sip@ietf.org; Thu, 05 Oct 2006 17:46:14 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVb2i-0004g4-OL for sip@ietf.org; Thu, 05 Oct 2006 17:46:14 -0400 Received: from [160.39.246.147] (dyn-wireless-246-147.dyn.columbia.edu [160.39.246.147]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k95LFi824362; Thu, 5 Oct 2006 15:15:44 -0600 Message-ID: <452575F8.8020308@ntt-at.com> Date: Thu, 05 Oct 2006 14:15:36 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) 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: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Gonzalo.Camarillo@ericsson.com, dean.willis@softarmor.com Subject: [Sip] Review of draft-ietf-sip-consent-framework-00.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 Draft: draft-ietf-sip-consent-framework-00.txt Reviewer: Shida Schubert Review Date: 28 Sept 2006 Review Deadline: 17 Oct 2006 Status: WGLC Summary: This draft needs some clarification and some security considerations before moving forward. Question for clarification: ---------------------------- 1. The Consent-FW allows recipient to grant or deny relay from conducting translation but there is no mentioning of how senders are granted to send message to the target-URI which gets translated to one or more messages aimed for each recipient URI in the translation logic. This may not be needed if sender is limited to a unique sender but since one can set "any" as sender in consent format, it can become quite problematic. As there is no authorization policy to restrict a sender from sending the message, any malicious user who has access to the target-URI seems to have the ability to abuse the target-URI and ban-burden the recipients who have granted the translation. Additional question is, are any users granting the translation also allowed to send the message to the target-URI to request translation? If we look at the mailing list which is very similar in concept you usually are. 2. Section 5.4, 7th paragraph, 2nd sentence describes how the permission document may request permission for any relay to forward requests > It's not clear how this works. It sounds as though permission document submitted to the entity (relay) represented by the URI contained in the permission document is distributed(propagated) to all the relays?? I can understand if you can specify a relay by domains but what does "any" relay really mean? And how would the permission document triggered by "Trigger-Consent" look like? Would it have the "any" as a relay(Original recipient) or only the URI of the original recipient which invoked the "trigger-consent" action? 3. Although reading both the permission document and the framework document, one can imagine how the state of the permission would change but there is no recommendation as to when the state should be X in neither of the documents, which I think may be useful if text is added. 4. There is no text on how the permission document should be displayed to the user(What contents to display in case the UA user uses does not support this FW)? It may be out of scope but necessary information to submit the authorization decision may be presented as a recommendation may be useful. 5. There is no way to express the authentication methods used by relay to authenticate the permission document submitted by the recipient. I think this needs to be communicated somehow or at least one method must be mandatory to implement/support on both the UA/relay supporting this mechanism. 6. It's possible that user only wants to accept a particular call such as PPT invitation represented as a target-URI on a particular device. Should we allow user to change the recipient URI in the permission document so may be user can change the AoR to GRUU pointing to a particular instance?? 7. There is no way to express the reason user rejected the authorization for translation. It's possible that user would have granted the translation if the sender was limited to user A and B or if the recipient URI was a particular contact address(GRUU). Should we allow the UA to change the permission document at all? 8. Section 5.6.1, does not describe how exactly the identity matching is done? Does it compare the value in FROM header to the recipient URI in the permission document? If so UA better make sure it sets the value recommended and the recommendation better be described here. * UA can obtain a SIP-Identity without putting a proper AoR according to the RFC 4474 AFAIK. 9. Section 5.9 describes the behavior of the relay when the recipient has not granted the translation but the behavior of relay when its not dealing with the URI-list service for a similar situation is unspecified. 10. I think in the security consideration, the authentication of the user who modifies the translation logic should be recommended. * AFAIK, the consent-fw allows me to trigger a MESSAGE with permission document to be sent with me pretending to be somebody else. (value of FROM is not authenticated.) It might be attractive enough for malicious user to have the ability to withhold identity and ban-burden others with meaningless messages. 11. This is related to permission documents but, permission documents AFAIR does not have any placeholder to describe why the permission is requested. I don't remember such element in common policy where one can describe such information. General comments: --------------- This might simply be my preference, and may not be suitable for FW document but I personally like it when the document is composed to describe each entity's behavior separately. >> UA's behavior, Relay's behavior, Proxy's behavior etc. Editorial nits: ---------------- Section 3: - Paragraph 6 last sentence: [ ADD "entity performing" before URI-list service if URI-list service describes function rather than an entity ] OLD: This relay may be, for instance, a proxy server or a URI-list service NEW: This relay may be, for instance, a proxy server or an entity performing URI-list service Section 4: - Paragraph 1 last sentence: [ REMOVE "permissions" ] OLD: Section 4.4 describes how potential recipients can grant a relay permissions to add them to the relay's translation logic. NEW: Section 4.4 describes how potential recipients can grant a relay to add them to the relay's translation logic. Section 4.1: - Paragraph 1 2nd sentence: [ADD "or denied" REMOVE "or not"] OLD: These permissions indicate if a particular recipient has agreed to receive traffic or not at any given time. NEW: These permissions indicate if a particular recipient has agreed or denied to receive traffic at any given time. - Paragraph 5 1st sentence: [ CHANGE SHOULD to MUST ] REASON: I don't think the service is of any use unless there is a way for UA to find out the pending status.. Reference > Update the reference to service-uri-services from 05 to 06. > Update the reference to consent-format from 00 to 01 Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 05 18:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVbIR-0004EI-PR; Thu, 05 Oct 2006 18:02:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVbIQ-0004CJ-Pe for sip@ietf.org; Thu, 05 Oct 2006 18:02:26 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVbIO-0007a0-9a for sip@ietf.org; Thu, 05 Oct 2006 18:02:26 -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 k95LtlU13573; Thu, 5 Oct 2006 17:55:48 -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] GRUU and Grid alternative Date: Thu, 5 Oct 2006 17:02:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110CAFE3D@zrc2hxm2.corp.nortel.com> In-Reply-To: <45257B6C.6090907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-index: AcboxsIQBBdx8X0HR0qLOZ12G5+TqQAAo2fg From: "Brian Stucker" To: "Paul Kyzivat" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 Right. If the P-Called can go away, great. However, if we are trying to address a problem *like* P-Called, which seemed to be a claim of the proposal, then it becomes important. P-Called happened to be a convenient proxy for the discussion. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, October 05, 2006 4:39 PM > To: Jonathan Rosenberg > Cc: Stucker, Brian (RICH1:AR00); IETF SIP List > Subject: Re: [Sip] GRUU and Grid alternative >=20 >=20 >=20 > Jonathan Rosenberg wrote: > > This is a good point; thanks Paul. > >=20 > > I think there is a deeper question here about whether the calling=20 > > party has a right to know the called party identity beyond the=20 > > information revealed by the GRUU. If the GRUU is anonymous,=20 > the caller=20 > > only has the anonymous URI, and presumably this is because=20 > the called=20 > > party wanted to remain anonymous. Should then the P-CSCF=20 > provide the=20 > > actual called party identity to the caller after the call=20 > completes? I=20 > > would think this is a bad thing and a violation of privacy, no? >=20 > Well, the P-Asserted-Identity in the response is largely=20 > there for use by servers in the trust domain. It can be=20 > removed before it exits the trust domain, so that it isn't=20 > made available to the caller, if desired.=20 > But I don't think that is currently done, and in fact may=20 > negate some of the intent of the feature. Typically it would=20 > only be removed in the forward direction based on the=20 > Privacy:id header. I don't think id privacy in the reverse=20 > direction is supported, though perhaps it could be. That=20 > might be the proper answer in this case. >=20 > It is a bit of a fuzzy area wrt the details of IMS, and in=20 > large part is probably not an issue for ietf. Presumably IMS=20 > can continue to use P-Called-Party-ID if they want to. And=20 > *maybe* they will find that it is no longer needed. We just=20 > don't know yet. >=20 > Paul >=20 > > -Jonathan R. > >=20 > > Paul Kyzivat wrote: > >> Unfortunately, I don't think this eliminates the need for=20 > >> P-Called-Party-ID in IMS. > >> > >> In IMS, when the AOR in the R-URI is translated to a=20 > contact address=20 > >> in the R-URI, a P-Called-Party-ID header is added=20 > containing that AOR. > >> Later, a downstream proxy (the terminating P-CSCF) remembers this=20 > >> value when forwarding the request to the UAS. Then when=20 > the response=20 > >> comes back from the UAS, that proxy adds a=20 > P-Asserted-Identity header=20 > >> using the value from the P-Called-Party-ID header of the=20 > request. In=20 > >> this way, the identity of the called party is asserted. Until now,=20 > >> plans to carry gruu into IMS have proposed that when a gruu is=20 > >> translated, the P-Called-Party-ID header should be set to the AOR,=20 > >> not the gruu. > >> > >> While we have lots of identity work in process that=20 > addresses similar=20 > >> issues in different ways. But meanwhile that is what IMS does. > >> > >> It depends on P-Called-Party-ID containing something=20 > suitable for use=20 > >> as an identity, suitable for authorization decisions, etc.=20 > To make=20 > >> this work with gruu, until now plans to carry gruu into IMS have=20 > >> proposed that when a gruu is translated, the=20 > P-Called-Party-ID header=20 > >> should be set to the AOR, not the gruu. > >> > >> If loose routing of the contact is adopted, and the=20 > P-Called-Party-ID=20 > >> usage is eliminated, then the identity of the called party=20 > would have=20 > >> to be inferred from the R-URI. For instance in this case if the=20 > >> callee was identified by an assigned anonymous gruu, then the=20 > >> identity coming back would have that, which wouldn't be=20 > very useful. > >> > >> At the moment, I expect that IMS may well continue to need=20 > >> P-Called-Party-ID even after this change. That of course=20 > is subject=20 > >> to further consideration, but lets not count our benefits=20 > until they=20 > >> have been confirmed. > >> > >> Paul > >> > >> Jonathan Rosenberg wrote: > >> > >>> I don't follow. The only P-header issue this solves is=20 > >>> P-Called-Party-ID. That header was added to deal exactly=20 > with this=20 > >>> issue of the r-uri being rewritten, so the UAS doesn't know which=20 > >>> public identity was targeted by the request. By not rewriting the=20 > >>> request URI that problem is eliminated. > >>> > >>> What trust-domain issues are you referring to? > >>> > >>> -Jonathan R. > >>> > >>> Brian Stucker wrote: > >>> > >>>> I believe what you are describing here is essentially=20 > extending the=20 > >>>> routing mechanism used within the IMS core network to route=20 > >>>> messages between various servers (x-CSCFs, BGCFs, App=20 > Servers, etc). > >>>> Although this may help with a number of issues, and on=20 > the face of=20 > >>>> it is a relatively simple idea (use a separate stack=20 > data structure=20 > >>>> for routing instead of a static URI) I don't think it solves all=20 > >>>> the problems you may think it does. > >>>> > >>>> For instance, existing P-headers also have a trust-domain and=20 > >>>> network assertion factor associated with them. > >>>> > >>>> Regards, > >>>> Brian > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent:=20 > >>>>> Wednesday, September 27, 2006 12:50 AM > >>>>> To: IETF SIP List > >>>>> Subject: [Sip] GRUU and Grid alternative > >>>>> > >>>>> During our call on GRUU last week, there was a=20 > discussion on this=20 > >>>>> issue that ekr raised, where he would like to see the=20 > grid usable=20 > >>>>> outside of just gruu, i.e., with any AOR. > >>>>> > >>>>> During the call, I made a suggestion for an alternative=20 > solution,=20 > >>>>> and there was agreement amongst those on the call for=20 > the proposed=20 > >>>>> approach. > >>>>> > >>>>> The basic idea would be to remove the grid mechanism=20 > entirely from=20 > >>>>> the gruu draft. Instead, a separate specification would be=20 > >>>>> developed which would allow for loose routing to apply to user=20 > >>>>> agents. So, consider a UA which registers. It would include a=20 > >>>>> contact and a Supported header field with the value "ua-route".=20 > >>>>> The registrar, assuming it understands this, notes that the UA=20 > >>>>> supports UA loose routing and stores the contact. When=20 > an incoming=20 > >>>>> call arrives for the AOR, rather than rewriting the=20 > R-URI with the=20 > >>>>> registered contact, it pushes the registered contact=20 > into a Route=20 > >>>>> header and leaves the R-URI alone (assuming the registered UA=20 > >>>>> supports this mechanism). > >>>>> > >>>>> How does this solve the grid problem? Lets say my AOR is=20 > >>>>> sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some=20 > >>>>> arbitrary parameter, say sip:jdrosen@cisco.com;foo=3Dbaz,=20 > and hand=20 > >>>>> it out to some correspondent. When a correspondent=20 > sends a request=20 > >>>>> to that URI, it arrives at my home proxy. From there, since the=20 > >>>>> R-URI is NOT rewritten, the entire URI, parameters and all, is=20 > >>>>> passed to the UA. Thus, the UA knows the URI that was=20 > >>>>> de-referenced. We wouldn't necessarily have to standardize a=20 > >>>>> specific URI parameter, like grid, to carry the opaque data. > >>>>> > >>>>> This trick solves a whole bunch of other problems too. It would=20 > >>>>> eliminate the need for the IMS P-Called-Party-ID header=20 > field, and=20 > >>>>> it would help clarify when a request is retargeted (change in > >>>>> R-URI) vs. when its just being delivered to the recipient (no=20 > >>>>> change in R-URI). > >>>>> > >>>>> Comments? > >>>>> > >>>>> -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 > >>>>> > >>>> > >>>> > >>> > >> > >=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 Oct 06 05:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVlz5-0001Cr-Ju; Fri, 06 Oct 2006 05:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVlz4-0001Bp-BU for sip@ietf.org; Fri, 06 Oct 2006 05:27:10 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVlz0-00008N-KK for sip@ietf.org; Fri, 06 Oct 2006 05:27:10 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k969R5vp026364; Fri, 6 Oct 2006 11:27:05 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k969R2KM020479; Fri, 6 Oct 2006 11:27:05 +0200 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 11:26:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Oct 2006 11:26:38 +0200 Message-ID: <72963DDDF17D7949ABD18DC5DA58E770016B02D3@MCHP7R5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New comment to draft-niemi-sip-subnot-etags-01 thread-index: AcbpKYYDZ8A1csXXS8GIthfy/Unqnw== From: "Schmidt, Christian" To: "Aki Niemi" X-OriginalArrivalTime: 06 Oct 2006 09:26:40.0661 (UTC) FILETIME=[87B8E450:01C6E929] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] New comment to draft-niemi-sip-subnot-etags-01 X-BeenThere: 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="===============0510389977==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0510389977== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E929.8710271E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E929.8710271E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Aki, =20 in general, I like your idea, to reduce number and length of messages for the presence service, by avoiding redundant information - without adding much complexity. =20 But in case of a subscription refresh (to extend the subscription time), it could be done easier (e.g. without etag). - Watcher send a SUBSCRIBE with "no additional notify needed" - Presence server changes timeout of service and acknowledge it to the watcher via 200 message. - If there is any change of presenty information, this specific watcher will be informed via NOTIFY message, independent from the subscription refresh.=20 What do you think about? =20 PS: The case fetching or polling of resource state should be described in more details (e.g. messages). =20 Regards=20 Christian Schmidt, Siemens=20 =20 =20 ------_=_NextPart_001_01C6E929.8710271E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Aki,
 
in = general, I like=20 your idea, to reduce number and length of messages for the presence = service, by=20 avoiding redundant information - without adding much=20 complexity.
 
But in = case of a=20 subscription refresh (to extend the subscription time), it could be done = easier=20 (e.g. without etag).
- = Watcher send a=20 SUBSCRIBE with "no additional notify needed"
- = Presence server=20 changes timeout of service and acknowledge it to the watcher via 200=20 message.
- If = there is any=20 change of presenty information, this specific watcher will be = informed via=20 NOTIFY message, independent from the subscription=20 refresh. 
What = do you think=20 about?
 
PS: = The case=20 fetching or polling of resource state should be described in more = details (e.g.=20 messages).
 
Regards=20
Christian Schmidt, = Siemens=20

 

 
------_=_NextPart_001_01C6E929.8710271E-- --===============0510389977== 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 --===============0510389977==-- From sip-bounces@ietf.org Fri Oct 06 12:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsGe-0001e6-5W; Fri, 06 Oct 2006 12:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsGc-0001e1-Jv for sip@ietf.org; Fri, 06 Oct 2006 12:09:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsGa-0001eB-8q for sip@ietf.org; Fri, 06 Oct 2006 12:09:42 -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 k96FCjvl000795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Oct 2006 10:12:46 -0500 Message-ID: <45268005.3050103@softarmor.com> Date: Fri, 06 Oct 2006 11:10:45 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "Xia, Zhi Feng \(Bruce\)" Subject: Re: [Sip] An reference error in rfc 3420 References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Xia, Zhi Feng (Bruce) wrote: > Hi, > There's a reference error in 3420: > > Normative References > > [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., > Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: > Session Initiation Protocol", RFC 3265, June 2002. > ^^^^^^^^^^^^^should be RFC3261 > > Regards, > Zhifeng > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > yes, that's a published errata item for the RFC. See: http://www.rfc-editor.org/cgi-bin/errataSearch.pl 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 Fri Oct 06 12:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsmB-0003sZ-Pl; Fri, 06 Oct 2006 12:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsmA-0003sS-AD for sip@ietf.org; Fri, 06 Oct 2006 12:42:18 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsm7-0001PI-Ub for sip@ietf.org; Fri, 06 Oct 2006 12:42:18 -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 k96FjLWr000886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Oct 2006 10:45:22 -0500 Message-ID: <452687A9.9050403@softarmor.com> Date: Fri, 06 Oct 2006 11:43:21 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> In-Reply-To: <17701.27248.192068.881081@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > jonathan, > > many sip phones on the market use as host part of r-uri their own > domain. for example, if a phone in domain foo.bar makes call to local > number 2345657, the phone will send out r-uri sip:234567@foo.bar. > > when that request hits foo.bar's proxy, it usually canonized the number > that, for example, results in r-uri sip:+35640234567@foo.bar. then the > proxy may make an enum query and find out that the r-uri needs to be > re-written as sip:jh@tutpro.com. the proxy then re-writes r-uri > accordingly and sends the request to tutpro.com's proxy. > > my question is, are you suggesting that when the request hit's > tutpro.com's proxy, its request uri is still sip:234567@foo.bar and that > route header contains sip:jh@tutpro.com? if so, what is the difference > between r-uri and to uri? why do we need both? I would say that tutpro.com's proxy is actually retargeting the request, not routing the request. It can retarget the request because it is the authoritative proxy for the domain-part. This is a "change of target" operation. Similar considerations apply for speed-dial services. Let's say I have a service that allows me to dial number@softarmor.com and get that translated into a longer URI. For example, I might dial "7@softarmor.com" to get routed to my girlfriend. Of course, I don't want her thinking that she's #7 on my list -- I either want her to think she's #1, or not thinking she's on a "list" at all. So I want my speed-dial service to retarget the request, by which I mean I want it to replace the request URI "sip:7@myspeedial.example.net" with the more AOR "sip:hotchick29@escortservice.example.com" (or whatever the appropriate AOR is). So, there are cases that demand request routing, and cases that demand request retargeting. Any proxy can route, but (afaik) only a proxy responsible for the request URI can retarget. One of the cases that we've done retargeting in that does NOT benefit from it is the application of contact-routing, wherein a request sent to an AOR is retargeted to a Contact" value. This should be a routing operation -- we haven't changed the target, we've just routed the request to a node that we believe can handle requests for that target and that needs to know what the target was. Of course, we need to remain aware that any time we do a retargeting operation at a proxy we complicate the "response identity" problem by introducing a potentially unexpected respondent. I think the general rule of thumb is that once a request's URI has been transformed into an AOR (and it might start out that way, or might not) that most cases need routing and not retargeting for further handling. Let's clarify that a bit while thinking about response identity. Routing (as opposed to retargeting) to the Contact makes it fairly easy for the UAS to figure out what identity to assert when responding to a request, should we have a means to do that assertion. For example, I might have my phone registered for both dean.willis@softarmor.com and deawilli@cisco.com. There's a cert for each identity, copies of which are stored in the phone. But the certs for these two identities are different, so the phone needs to know which cert to apply on a response. It can do this by picking the cert based on the request URI, if we did contact-routing according to Jonathan's proposal. The "To:" header is not so useful, because it might contain completely irrlevant information. But let's say I'm going on vacation for a few months (I'm thinking European, as Americans don't actually have vacations like this) and wish to forward my calls to Jonathan. Jonathan doesn't have my cert and can't authenticate as me. So I probably want to retarget those requests to him, not route them. We still have an unanticipated respondent -- callers get Jonathan (and his cert), not me, but that's ok. I would like to see a proxy that retargets a request send something back to the UAC (perhaps a reliable provisional) indicating that the call has been retargeted and informing the caller of the anticipated new target (potentially even provising authentication data for the new target) so that we can eliminate the "unanticipated response" problem. But I think we can do that as a separate body of work. -- 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 Oct 06 13:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtYI-0006lf-CR; Fri, 06 Oct 2006 13:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtYG-0006g2-Op for sip@ietf.org; Fri, 06 Oct 2006 13:32:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVtYF-00087b-A7 for sip@ietf.org; Fri, 06 Oct 2006 13:32:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2006 10:31:44 -0700 X-IronPort-AV: i="4.09,273,1157353200"; d="scan'208"; a="45124159:sNHT62481344" 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 k96HVefX011316; Fri, 6 Oct 2006 13:31:40 -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 k96HVdYL017003; Fri, 6 Oct 2006 13:31:39 -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, 6 Oct 2006 13:31:39 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 13:31:39 -0400 Message-ID: <452692FA.5000709@cisco.com> Date: Fri, 06 Oct 2006 13:31:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> In-Reply-To: <452687A9.9050403@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2006 17:31:39.0310 (UTC) FILETIME=[47DE5CE0:01C6E96D] DKIM-Signature: a=rsa-sha1; q=dns; l=5552; t=1160155900; x=1161019900; 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=20Grid=20alternative |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3D37wdfzTcXxsKFn2cKwMMZsWTSx8=3D; b=cXaesq5N+4LtuJeFHMYHjI9HTcD/4XLkyzLDGSdBw+5+dq7Qs831EVJof3xHGTjebCJDNVjv Dcgs/29v6rRm0F/M4Dnf9VYYH3ajLYCCp4jLwX6EVW8DZOjbvFMw5igH; 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: 2857c5c041d6c02d7181d602c22822c8 Cc: IETF SIP List , Juha Heinanen , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I pretty much agree with you. Regarding response identity and your example: you called sip:7@myspeedial.example.net, and your server retargeted to sip:brittney@spears.tv. So you are suggesting that your server should notify you this happened, so that when you received response identity you will not be surprised. Instead of this, how about having the proxy remain on the path and insert a response identity for 7@myspeedial.example.net at least in requests/responses that carry some other identity? Regarding not wanting Brittney to know she's #7: what will you do about the To header? Paul Dean Willis wrote: > Juha Heinanen wrote: >> jonathan, >> >> many sip phones on the market use as host part of r-uri their own >> domain. for example, if a phone in domain foo.bar makes call to local >> number 2345657, the phone will send out r-uri sip:234567@foo.bar. >> >> when that request hits foo.bar's proxy, it usually canonized the number >> that, for example, results in r-uri sip:+35640234567@foo.bar. then the >> proxy may make an enum query and find out that the r-uri needs to be >> re-written as sip:jh@tutpro.com. the proxy then re-writes r-uri >> accordingly and sends the request to tutpro.com's proxy. >> >> my question is, are you suggesting that when the request hit's >> tutpro.com's proxy, its request uri is still sip:234567@foo.bar and that >> route header contains sip:jh@tutpro.com? if so, what is the difference >> between r-uri and to uri? why do we need both? > > I would say that tutpro.com's proxy is actually retargeting the request, > not routing the request. It can retarget the request because it is the > authoritative proxy for the domain-part. > > This is a "change of target" operation. > > Similar considerations apply for speed-dial services. > > Let's say I have a service that allows me to dial number@softarmor.com > and get that translated into a longer URI. For example, I might dial > "7@softarmor.com" to get routed to my girlfriend. Of course, I don't > want her thinking that she's #7 on my list -- I either want her to think > she's #1, or not thinking she's on a "list" at all. So I want my > speed-dial service to retarget the request, by which I mean I want it to > replace the request URI "sip:7@myspeedial.example.net" with the more AOR > "sip:hotchick29@escortservice.example.com" (or whatever the appropriate > AOR is). > > So, there are cases that demand request routing, and cases that demand > request retargeting. Any proxy can route, but (afaik) only a proxy > responsible for the request URI can retarget. > > One of the cases that we've done retargeting in that does NOT benefit > from it is the application of contact-routing, wherein a request sent to > an AOR is retargeted to a Contact" value. This should be a routing > operation -- we haven't changed the target, we've just routed the > request to a node that we believe can handle requests for that target > and that needs to know what the target was. > > Of course, we need to remain aware that any time we do a retargeting > operation at a proxy we complicate the "response identity" problem by > introducing a potentially unexpected respondent. > > I think the general rule of thumb is that once a request's URI has been > transformed into an AOR (and it might start out that way, or might not) > that most cases need routing and not retargeting for further handling. > > Let's clarify that a bit while thinking about response identity. > > Routing (as opposed to retargeting) to the Contact makes it fairly easy > for the UAS to figure out what identity to assert when responding to a > request, should we have a means to do that assertion. > > For example, I might have my phone registered for both > dean.willis@softarmor.com and deawilli@cisco.com. There's a cert for > each identity, copies of which are stored in the phone. But the certs > for these two identities are different, so the phone needs to know which > cert to apply on a response. It can do this by picking the cert based on > the request URI, if we did contact-routing according to Jonathan's > proposal. The "To:" header is not so useful, because it might contain > completely irrlevant information. > > But let's say I'm going on vacation for a few months (I'm thinking > European, as Americans don't actually have vacations like this) and wish > to forward my calls to Jonathan. Jonathan doesn't have my cert and can't > authenticate as me. So I probably want to retarget those requests to > him, not route them. We still have an unanticipated respondent -- > callers get Jonathan (and his cert), not me, but that's ok. > > I would like to see a proxy that retargets a request send something back > to the UAC (perhaps a reliable provisional) indicating that the call has > been retargeted and informing the caller of the anticipated new target > (potentially even provising authentication data for the new target) so > that we can eliminate the "unanticipated response" problem. But I think > we can do that as a separate body of work. > > -- > 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 Oct 06 14:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVuBu-0003Oy-LB; Fri, 06 Oct 2006 14:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV3Fj-0005O3-4j for sip@ietf.org; Wed, 04 Oct 2006 05:41:23 -0400 Received: from [206.191.54.231] (helo=icp3050.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GV3Fh-0004c3-LJ for sip@ietf.org; Wed, 04 Oct 2006 05:41:23 -0400 Received: (qmail 7724 invoked by uid 453); 4 Oct 2006 09:41:17 -0000 Received: from pc-00151.icp3050.com (HELO mkcpmusgrave1d) (192.168.100.151) by icp3050.com (qpsmtpd/0.31.1) with ESMTP; Wed, 04 Oct 2006 05:41:17 -0400 From: "Peter Musgrave" To: Date: Wed, 4 Oct 2006 05:39:53 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbnmQt0gkUxRs6FSUeK4xKxko8A/g== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 X-Mailman-Approved-At: Fri, 06 Oct 2006 14:12:57 -0400 Subject: [Sip] GRUU - Register with illegal contact X-BeenThere: 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="===============0986149056==" Errors-To: sip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0986149056== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C6E777.8587ECC0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C6E777.8587ECC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In the GRUU draft (7.1.2.1) is the statement that a REGISTER which contains a Contact: header which has a gruu and a +sip-instance is to be ignored by the registrar. I'm not clear on the correct SIP response in the cases where a) the REGISTER had one Contact entry b) there were multiple Contacts (others which are valid) in the request I'd be inclined to implement this as a) return a 400 Bad Request b) return an OK with the valid contacts listed and omit the invalid contact Is this sensible? Does the required behavior need to specified explicitly in the draft? Thanks, Peter Musgrave ------=_NextPart_000_0003_01C6E777.8587ECC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the GRUU draft (7.1.2.1) is the statement that a = REGISTER which contains a Contact: header which has a gruu and a +sip-instance is = to be ignored by the registrar.

 

I’m not clear on the correct SIP response in = the cases where

a)       = the REGISTER had one Contact entry

b)       = there were multiple Contacts (others which are valid) in the = request

 

 

I’d be inclined to implement this = as

a)       = return a 400 Bad Request

b)       = return an OK with the valid contacts listed and omit the invalid = contact

 

Is this sensible?

Does the required behavior need to specified = explicitly in the draft?

 

Thanks,

 

Peter Musgrave

------=_NextPart_000_0003_01C6E777.8587ECC0-- --===============0986149056== 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 --===============0986149056==-- From sip-bounces@ietf.org Fri Oct 06 15:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVviC-0006iK-Ow; Fri, 06 Oct 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVvhs-0006fK-6q; Fri, 06 Oct 2006 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVvhp-0004RA-UY; Fri, 06 Oct 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id DFBCF32901; Fri, 6 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVvhp-00021F-Fw; Fri, 06 Oct 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: Fri, 06 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-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 : Connected Identity in the Session Initiation Protocol (SIP) Author(s) : J. Elwell, et al. Filename : draft-ietf-sip-connected-identity-02.txt Pages : 25 Date : 2006-10-6 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) and RFC 4474 (SIP Identity). 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-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-connected-identity-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-connected-identity-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-10-6101848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connected-identity-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connected-identity-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-6101848.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 Sun Oct 08 04:21:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWTp9-00076R-1M; Sun, 08 Oct 2006 04:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWTp7-00076L-O9 for sip@ietf.org; Sun, 08 Oct 2006 04:15:49 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWTp4-0008Ck-B7 for sip@ietf.org; Sun, 08 Oct 2006 04:15:49 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k988Fao2024088 for ; Sun, 8 Oct 2006 03:15:37 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Oct 2006 16:15:00 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 8 Oct 2006 16:15:00 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] Re: [Sip-implementors] Early media query Date: Sun, 8 Oct 2006 16:15:00 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Sip-implementors] Early media query thread-index: AcbojtSlCyVAWMfNSfW22wxkM47w2ACIhlYQ From: "Xia, Zhi Feng \(Bruce\)" To: "Paul Kyzivat" , "Darshan Bildikar" X-OriginalArrivalTime: 08 Oct 2006 08:15:00.0660 (UTC) FILETIME=[D98C4F40:01C6EAB1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, Retesh Chadha , sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Given the restrictions in RFC, all four methods seem invalid. Before we can change the restrictions in the RFC, it looks to me using = "replaces" is a better approach... How about this flow: > Caller Callee > | | > | | > |(1) INVITE with offer | > |----------------------------> | > | | > | | > |(2) 183 with answer 1 | > |<-------------------------------| > | | > | | > |(3) PRACK | > |----------------------------> | > | | > | | > |(4) 200 PRACK | > |<------------------------------| > |(5) 200 OK | > |<---------------------------- | > | | > |(6) ACK | > |---------------------------->| > | | > |(7)Re-INVITE(replaces with new call id) > |<----------------------------| > | NOTIFY | |-----------------------------> |BYE(the original call id) |-----------------------------> > | | > |(8) 200 OK with SDP | > |---------------------------->| > | | > |(9) ACK | > |---------------------------->| -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 2006?10?5? 22:52 To: Darshan Bildikar Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; 'Retesh Chadha' Subject: [Sip] Re: [Sip-implementors] Early media query Darshan Bildikar wrote: > I don't think that even Method 3 and 4 are OK because they will = involve a > change in the origin line parameter of the SDP and that is not allowed = as > per the RFC.=20 Which RFC? I suport Crister's response. Paul > BTW, what was the rationale behind not allowing the origin line to = change? > It makes implementing apps like prepaid and CRBT very difficult. Could > someone please throw some light on this? >=20 > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh = Chadha > Sent: Monday, October 02, 2006 5:46 PM > To: Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Early media query >=20 > Hi Udit > Of all the methods you have specified, Method 1 and 2 are wrong as per > the RFC which states that the sdp of all the provisional and 2xx > response of INVITE should be same if they are present. >=20 > Both Method 3 and 4 look fine, with method 4 being better because in > that case 200 ok for INVITE is only sent when the final negotiation > (call media) is done. >=20 > Hope this helps. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Oct 08 11:46:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWamx-0008Dd-4u; Sun, 08 Oct 2006 11:42:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWamv-0008DY-JR for sip@ietf.org; Sun, 08 Oct 2006 11:42:01 -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 1GWams-0004pm-3Z for sip@ietf.org; Sun, 08 Oct 2006 11:42:01 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6T00101Q9XEB@siemenscomms.co.uk> for sip@ietf.org; Sun, 08 Oct 2006 16:41:57 +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 <0J6T00M6BQ9XVJ@siemenscomms.co.uk> for sip@ietf.org; Sun, 08 Oct 2006 16:41:57 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9S4FVB>; Sun, 08 Oct 2006 16:41:44 +0100 Content-return: allowed Date: Sun, 08 Oct 2006 16:41:44 +0100 From: "Elwell, John" Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-02.txt To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F26670A082285@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: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Version 02 reflects comments received during WGLC. I am concerned I have not received sufficient consensus regarding the first of the changes listed below, so take a careful look at that. Otherwise I think it is ready to go. Changes: - Update of RFC 4474 procedures for a verifier to soften requirements for rejecting a signature, particularly for mid-dialog requests. See new section 4.6. - Removal of background material on existing identity and authentication mechanisms to appendix. - Change of name of option tag to "from-change". - Mention the need for a proxy providing an Authentication Service or Verifier to record route. - Explanation why the option tag does not need to be used in a Require header field. - Explicit indications of what constitutes the change to RFC 3261. - Added note that sending Supported: from-change does not guarantee that connected identity will be received in subsequent requests. - Substructuring of 4.4 into send and receive. - Added text on receiving 428, 436, 437 and 438 response. - Insertion of signatures in examples (although these are known to be wrong because of change to option tag name - will be re-computed during auth48 if not before). - Additions to security section concerning missing Identity header field and use of History-Info as clue to reason for retargeting. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 06 October 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-02.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, et al. > Filename : draft-ietf-sip-connected-identity-02.txt > Pages : 25 > Date : 2006-10-6 > > 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) and RFC > 4474 (SIP Identity). > > 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-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-connected-identity-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-connected-identity-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. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 08 11:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWaty-00043d-Q8; Sun, 08 Oct 2006 11:49:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWatx-00043X-Pa for sip@ietf.org; Sun, 08 Oct 2006 11:49:17 -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 1GWatw-0005j8-Tf for sip@ietf.org; Sun, 08 Oct 2006 11:49:17 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6T00301QMG7U@siemenscomms.co.uk> for sip@ietf.org; Sun, 08 Oct 2006 16:49:28 +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 <0J6T0022QQMGL5@siemenscomms.co.uk>; Sun, 08 Oct 2006 16:49:28 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9S4FVP>; Sun, 08 Oct 2006 16:49:15 +0100 Content-return: allowed Date: Sun, 08 Oct 2006 16:49:10 +0100 From: "Elwell, John" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) To: Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A082286@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: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: Cullen Jennings , SIP , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Your message arrived just after I had submitted 02, so your comments are not taken into account in that version. However, I felt it was useful to get 02 out as a baseline for further discussion. It seems the remaining issue is whether to add an explicit indication of removal of the Identity header field by a verifier that has been unable to verify the signature. Whilst this may make sense, I am concerned it starts to go beyond the scope of connected-identity, so I would like other opinions, especially from the chairs and from the authors of Identity. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 05 October 2006 16:29 > To: Elwell, John > Cc: Cullen Jennings; Jon Peterson; SIP > Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > draft-ietf-si p-connecte d-id entity-01 comments) > > > > Elwell, John wrote: > > Paul, > > > > So your proposal is that the connected-identity RFC should > update RFC 4474 > > to somehow relax rules at a verifier. Correct? > > Yeah, I think so. > > > So the next question concerns the way in which these rules should be > > relaxed. One problem with the verifier not being located at > the UAS but at > > some proxy is that the UAS might be configured always to > trust identities > > received in requests via the verifier's proxy if an > Identity header field is > > present, on the assumption that the signature has been > checked by the > > verifier. Therefore it sounds like the verifier, if it does > not reject a > > request with a bad signature, should remove the Identity > header field (and > > also Identity-Info) before forwarding the request towards > the target. > > (I think I have seen someone propose combining the use of > Identity and > P-Asserted-Identity, though I don't recall the details, or > which draft > it was. So what I am about to say might bear no relationship to that.) > > I could see how Identity might be used between trust domains, while > P-Asserted-Identity is used within a trust domain. In that case, a > verifier might run at the entry point to a trust domain and if > verification succeeds, insert a P-Asserted-Identity header with a > corresponding identity. It then might, or might not, remove > the Identity > header. Recipients within the trust domain could then use > P-Asserted-Identity as the source of identity info. (In this > scenario, > an identity header would only be added to requests when they > leave the > trust domain.) > > In this kind of environment, it is only necessary for the verifier to > omit the P-Asserted-Identity header when verification fails. > > > Under what conditions should a verifier remove an Identity > header field > > rather than rejecting with 436/437/438? My inclination > would be to leave it > > as a matter of policy as far as the update to RFC 4474 is > concerned, and > > then make more precise statements concerning mid-dialog requests. > > Alternatively the update to RFC 4474 could just relax the rules for > > mid-dialog requests. I think there is some merit in > relaxing the rules in > > general, because otherwise there might be situations where > a legitimate > > caller cannot establish a call because an Authentication > Service (outside > > the UAC's control) is inserting an unverifiable signature (e.g., in > > Identity-Info placing a URL that the Verifier cannot > dereference for some > > reason). > > What you say sounds reasonable to me. > > There is however some risk to having a verifier remove identity. The > problem would be when there are potentially multiple verifiers that > don't trust one another. If an early one removes the header, then it > prevents a subsequent verifier from doing its own verification. > > This could come up if a request transits a domain on the way > to another > domain. Each domain may wish to do its own verification. > > That is an advantage to having the verifier add something to > the request > to indicate the result of its verification. > > > One consequence of the Verifier being separated from the > UAS is that we > > don't want to rely on stateful behaviour at the Verifier or > its proxy (for > > similar reasons that you cited for the Authentication > Service earlier). So > > for mid-dialog requests we would need to mandate, or at > least recommend, > > that 436/437/438 should not be sent. > > Right. > > Paul > > > John > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 03 October 2006 01:44 > >> To: Elwell, John > >> Cc: Cullen Jennings; Jon Peterson; SIP > >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >> draft-ietf-sip-connecte d-id entity-01 comments) > >> > >> > >> > >> Elwell, John wrote: > >>> Thinking further on this, perhaps there is a 4th way: > >>> > >>> 4. Specify that if a UAS rejects a mid-dialog request with > >> 436, 437 or 438, > >>> then it MUST NOT invoke the verifier for a subsequent request > >> This assumes that the verifier is invoked by the UAS, and > not by some > >> proxy in front of the UAS. Isn't it valid to have a verifier > >> in a proxy > >> before the UAS? This rule would forbid that, because it would > >> cause that > >> proxy to be call stateful. > >> > >> I think it would just be better to update the RFC, even > >> though that is a > >> bit more trouble than not to. > >> > >> Paul > >> > >>> on the same > >>> dialog unless the From header field URI has changed, and in > >> such cases > >>> SHOULD NOT make use of the unverified connected-identity. > >> Then a UAC, on > >>> receiving 436, 437 or 438, MUST repeat the request once. > >> This would allow > >>> business as usual on this dialog (but without the benefit > >> of connected > >>> identity, therefore no worse than at present). It avoids > >> any change to RFC > >>> 4474, because verification is optional anyway. > >>> > >>> Would this work? > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Elwell, John > >>>> Sent: 26 September 2006 21:02 > >>>> To: Cullen Jennings; Jon Peterson > >>>> Cc: SIP; Paul Kyzivat > >>>> Subject: FW: Rejecting connected identity (was RE: > >>>> draft-ietf-sip-connected-id entity-01 comments) > >>>> > >>>> Cullen, Jon, > >>>> > >>>> In case you missed this (it wasn't addressed directly to > >>>> you), I would greatly appreciate an opinion from each of you > >>>> on this remaining issue in connected-identity. Just to > >>>> summarise, RFC 4474 leaves it up to policy whether to return > >>>> a 428 response if Identity is missing, but mandates the > >>>> sending of a 436, 437 or 438 response for certain errors > >>>> arising while verifying the signature. It seems that for mid > >>>> dialog requests this behaviour could be harmful. What does > >>>> the UAC for the mid dialog request do if it receives 436, 437 > >>>> or 438? If the mid-dialog request was solely for the purpose > >>>> of connected identity, it can give up and allow the call to > >>>> continue as is. But if the request was for some other purpose > >>>> (e.g., renegotiating the session because of hold, say, or > >>>> session timer refresh), the UAC really wants it to work. For > >>>> the normal case where the Authentication Service is at a > >>>> proxy, not at the UAC, the UAC cannot force the > >>>> Authentication Service to refrain from putting this > >>>> unverifiable signature in the mid-dialog request, so any > >>>> attempts to repeat the request would most likely be doomed to > >>>> getting the same response. > >>>> > >>>> It seems there are three things we could do, none very > attractive: > >>>> 1. Get connected-identity to modify the procedures of RFC > >>>> 4474 for a verifier by softening the requirements for sending > >>>> 436, 437 and 438 in response to mid-dialog requests. But then > >>>> a mid-dialog request from a rogue source would be accepted. > >>>> 2. Say that the Authentication Service should omit the > >>>> signing of mid-dialog requests if a previous attempt has > >>>> resulted in 436, 437 or 438. But this implies statefulness > >> at the AS. > >>>> 3. Accept the fact the mid-dialog requests can fail in this > >>>> way and therefore things like session refresh and session > >>>> renegotiation cannot be done, probably resulting in call > >>>> failure. Sounds bad, but it is no different from an initial > >>>> INVITE request, where there is nothing the UAC can do if the > >>>> AS inserts an Identity header that gets rejected with 436, > >> 437 or 438. > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: 22 September 2006 19:26 > >>>>> To: Elwell, John > >>>>> Cc: Cullen Jennings; SIP > >>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>> > >>>>> John, > >>>>> > >>>>> I want to hear what others, especially Jon and Cullen, have > >>>>> to say about > >>>>> this. > >>>>> > >>>>> It is of some concern to me that a call might fail > >> because of some > >>>>> problem with the identity mechanism when the same call > might have > >>>>> succeeded in the absence of any identity. > >>>>> > >>>>> But possibly the solution to this is policy in the > >>>>> implementation of the > >>>>> verifier. What to do in the case of the conditions that > >>>> lead to these > >>>>> errors could be configurable in the verifier: either to > >>>> generate the > >>>>> error or simply to remove the identity info from the > >>>> message. And the > >>>>> policy could conceivably vary based on attributes of the > >>>>> message, such > >>>>> as whether it is in-dialog or not. > >>>>> > >>>>> Does it require a change to 4474 to permit that kind of policy? > >>>>> > >>>>> It would be annoying if the end user had no control over the > >>>>> insertion > >>>>> and verification of identity, and it resulted in calls > >>>>> failing that the > >>>>> user would like to permit. But I suppose that is itself > a policy > >>>>> decision. There are certainly enterprises that want to exert > >>>>> that kind > >>>>> of control over what users are permitted to do. > >>>>> > >>>>> Paul > >>>>> > >>>>> Elwell, John wrote: > >>>>>> Paul, > >>>>>> > >>>>>> I agree with most of your points, and on reflection I think > >>>>> I agree that the > >>>>>> solution has to be with the verifier. > >>>>>> > >>>>>> I think RFC 4474 is not a problem as far as sending a 428 > >>>>> 'Use Identity > >>>>>> Header' response is concerned, because that is left to > >>>>> policy, so we could > >>>>>> say in connected-identity that policy should be to not > send 428. > >>>>>> > >>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>> because RFC 4474 says > >>>>>> that they MUST be sent under respective conditions. > >>>>> Interestingly, though, > >>>>>> there are other failure scenarios that can arise from the > >>>>> procedures of > >>>>>> section 6 of RFC 4474 for which no normative statement is > >>>>> given on how to > >>>>>> respond, e.g. invalid Date header field, signer not > >>>>> authoritative for the > >>>>>> domain. > >>>>>> > >>>>>> So one way to solve the present problem would be for the > >>>>> connected-identity > >>>>>> draft to modify verifier behaviour in RFC 4474 in the case > >>>>> of mid-dialog > >>>>>> requests. I guess this would mean that it would update RFC > >>>>> 4474 as well as > >>>>>> updating RFC 3261. But I don't like this, because it seems > >>>>> to remove some of > >>>>>> the security properties of RFC 4474. > >>>>>> > >>>>>> Another way would be to accept that 436, 437 and 438 > >>>>> responses will be sent, > >>>>>> and failure to verify a signature will therefore result in > >>>>> inability to > >>>>>> process the UPDATE or re-INVITE request, and hence if the > >>>> UPDATE or > >>>>>> re-INVITE request was for some other purpose such as > >>>>> session timer refresh > >>>>>> or modifying the session, that action will fail. Then the > >>>>> call will fail (in > >>>>>> the case of inability to refresh the session timer) or > >> the session > >>>>>> modification will fail. I guess this is somewhat analogous > >>>>> to caller ID > >>>>>> verification failure in an INVITE request - it is > >>>>> impossible to establish a > >>>>>> call if verification fails. Moreover, the UAC has no > >>>>> ability to rectify the > >>>>>> situation, since it is at the mercy of a proxy-based > >>>>> Authentication Service > >>>>>> that puts a rogue Identity header field in every request. > >>>>> In the connected > >>>>>> identity case, the only difference is that the call is > >>>>> already established > >>>>>> but is likely to fail if verification fails. > >>>>>> > >>>>>> Of course, if the mid-dialog request is indeed from the > >>>>> wrong source, then > >>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>> thing to do, and > >>>>>> overriding the verification procedures of RFC 4474 would > >>>>> indeed be the wrong > >>>>>> thing to do. So perhaps we just have to accept that these > >>>>> response codes can > >>>>>> be received and will lead to failure. > >>>>>> > >>>>>> So, my preferred way forward is simply to recommend not > >>>>> sending a 428 and > >>>>>> accept the consequences of other responses that the > >>>>> verifier might send. > >>>>>> John > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>> Sent: 22 September 2006 15:13 > >>>>>>> To: Elwell, John > >>>>>>> Cc: Cullen Jennings; SIP > >>>>>>> Subject: Re: [Sip] RE: > >>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>> > >>>>>>> Elwell, John wrote: > >>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>>>> When an Update is sent. Are there any conditions > under which > >>>>>>>>> it might > >>>>>>>>> be rejected. Bad identity for example. I think that > >>>>> might need a > >>>>>>>>> little discussion and also what the UA does when it sends > >>>>>>> an update > >>>>>>>>> with a no identity and it gets rejected. > >>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>> situation where it is > >>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>> purposes such as > >>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>> because connected > >>>>>>>> identity fails. > >>>>>>>> My proposed fix is as follows: > >>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>>>>> with 428 'Use > >>>>>>>> Identity Header'. > >>>>>>> I'm not sure about this. At the least I think this one needs > >>>>>>> some clear > >>>>>>> explanation of the SHOULD NOT - about the conditions when > >>>>> it can be > >>>>>>> violated. > >>>>>>> > >>>>>>> I see this as somewhat analogous to doing a digest > >>>> challenge on an > >>>>>>> in-dialog request. In some cases it is the right thing to do. > >>>>>>> > >>>>>>> A UA that imposes such a requirement will be limited in what > >>>>>>> it can do, > >>>>>>> but that may still be right in some cases. > >>>>>>> > >>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>> Identity header field > >>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>> dialog has resulted in > >>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or > >>>>>>> 438 'Invalid > >>>>>>>> Identity Header'. > >>>>>>> This requirement would force the authentication service to > >>>>> be dialog > >>>>>>> stateful, which is not ideal. Better to push the state > >>>>> back into the > >>>>>>> sender of the request. This may require a way for the UAC > >>>>> to tell the > >>>>>>> authentication service not to act. > >>>>>>> > >>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>>>> results in one of > >>>>>>>> these responses if the mid-dialog request was not solely > >>>>>>> for the purpose of > >>>>>>>> connected identity. If solely for the purpose of connected > >>>>>>> identity there is > >>>>>>>> no point in repeating it, so I will say "SHOULD NOT take > >>>>> any further > >>>>>>>> action". > >>>>>>> This seems wrong to me. > >>>>>>> > >>>>>>> I think that the remedy to these is in the verifier. The > >>>>>>> purpose of the > >>>>>>> verifier is ultimately to drive an authorization decision. If > >>>>>>> authorization would succeed in the absence of the > >>>>> identity, then the > >>>>>>> request should be permitted to continue as if the identity > >>>>>>> was not present. > >>>>>>> > >>>>>>> Unfortunately this would seem to require a revision to 4474 > >>>>>>> even though > >>>>>>> the paint is hardly dry on it. > >>>>>>> > >>>>>>> If this is done, then there is no need of a mechanism to > >>>> cause the > >>>>>>> authentication service *not* to authenticate. If this is > >>>>> *not* done, > >>>>>>> then that need remains, which will still require a > >>>> change to 4474. > >>>>>>> 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 > >>> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 08 14:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWdGc-0000gq-9e; Sun, 08 Oct 2006 14:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWdGa-0000ga-IU for sip@ietf.org; Sun, 08 Oct 2006 14:20:48 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWdGZ-0000Wi-A6 for sip@ietf.org; Sun, 08 Oct 2006 14:20:48 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20061008182046b11008dti3e>; Sun, 8 Oct 2006 18:20:46 +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 k98IKjUm001542 for ; Sun, 8 Oct 2006 14:20:45 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k98IKjP5001538; Sun, 8 Oct 2006 14:20:45 -0400 Date: Sun, 8 Oct 2006 14:20:45 -0400 Message-Id: <200610081820.k98IKjP5001538@dragon.ariadne.com> From: Dale.Worley@comcast.net To: sip@ietf.org In-reply-to: <451A10FD.8040809@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] GRUU and Grid alternative References: <451A10FD.8040809@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: sip@ietf.org X-Mailman-Version: 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 all for the good, but may I suggest a couple of amendments? One is to call it something other than "loose routing". While it's related to loose routing, it's not really the same thing. The essential functional difference is that the UA is able to recognize that when a request's request URI is the UA's AOR, the UA is to process the request, even though the rules of RFC 3263 do not specify that the UA's host is a target for the request URI. The other change is to reorganize how this information is presented to the UA. I think a change would make the mechanism both strictly upward compatible with RFC 3261, and also more general and useful. The RFC 3261 behavior is to remove the AOR from the request-URI and replace it with the contact-address. What you've suggested is to leave the AOR as the request-URI and add a Route header containing the hostpart of the contact-address. As an alternative, consider putting the contact-address in the request-URI and saving the AOR in a parameter of the new Via header. This method has a number of advantages, I think: - It's strictly upward compatible with RFC 3261, so it requires no negotiation between UA and proxy/registrar. - Since the full contact-address (not just its hostpart) is available in the request-URI on the hops from the proxy to the UA, there is no reduction in the information available for routing, which ensures that even the most complex current situations do not stop working. That is "Nothing can possibly break." (Unless an agent barfs on an unknown Via parameter.) - The UA can extract the information it needs -- "What variant of my GRUU was this request addressed to?" -- by scanning the Via headers, finding the first one with a "previous request URI" parameter", and checking that it is a GRUU for this contact-address. - In the general case of messy routing, and where all proxies implement this mechanism, a full trace of address rewriting is preserved in the Via's. The disadvantage is that this system might enlarge the Via's if it is used for all routing/rewriting actions. But if it is used only by proxies when forwarding requests that are addressed to GRUUs, it enlarges messages by about the same amount as your proposal. (This is similar to e-mail Received headers, which now often contain a "for" field giving the envelope address as seen by that host.) 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 Oct 08 16:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWfTE-00040Q-S7; Sun, 08 Oct 2006 16:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWfTD-00040L-P3 for sip@ietf.org; Sun, 08 Oct 2006 16:41:59 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWfTC-0001aM-AH for sip@ietf.org; Sun, 08 Oct 2006 16:41:59 -0400 Received: (qmail 28237 invoked by uid 0); 8 Oct 2006 20:41:43 -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 < >; 8 Oct 2006 20:41:43 -0000 Message-ID: <003601c6eb1a$2d63f380$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <451A10FD.8040809@cisco.com> <200610081820.k98IKjP5001538@dragon.ariadne.com> Subject: Re: [Sip] GRUU and Grid alternative Date: Sun, 8 Oct 2006 22:41:48 +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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Isn't this a subset of History-Info? Jeroen Dale.Worley@comcast.net wrote: > This is all for the good, but may I suggest a couple of amendments? > > One is to call it something other than "loose routing". While it's > related to loose routing, it's not really the same thing. The > essential functional difference is that the UA is able to recognize > that when a request's request URI is the UA's AOR, the UA is to > process the request, even though the rules of RFC 3263 do not specify > that the UA's host is a target for the request URI. > > The other change is to reorganize how this information is presented to > the UA. I think a change would make the mechanism both strictly > upward compatible with RFC 3261, and also more general and useful. > > The RFC 3261 behavior is to remove the AOR from the request-URI and > replace it with the contact-address. What you've suggested is to > leave the AOR as the request-URI and add a Route header containing the > hostpart of the contact-address. As an alternative, consider putting > the contact-address in the request-URI and saving the AOR in a > parameter of the new Via header. > > This method has a number of advantages, I think: > > - It's strictly upward compatible with RFC 3261, so it requires no > negotiation between UA and proxy/registrar. > > - Since the full contact-address (not just its hostpart) is available > in the request-URI on the hops from the proxy to the UA, there is no > reduction in the information available for routing, which ensures > that even the most complex current situations do not stop working. > > That is "Nothing can possibly break." (Unless an agent barfs on an > unknown Via parameter.) > > - The UA can extract the information it needs -- "What variant of my > GRUU was this request addressed to?" -- by scanning the Via headers, > finding the first one with a "previous request URI" parameter", and > checking that it is a GRUU for this contact-address. > > - In the general case of messy routing, and where all proxies > implement this mechanism, a full trace of address rewriting is > preserved in the Via's. > > The disadvantage is that this system might enlarge the Via's if it is > used for all routing/rewriting actions. But if it is used only by > proxies when forwarding requests that are addressed to GRUUs, it > enlarges messages by about the same amount as your proposal. > > (This is similar to e-mail Received headers, which now often contain a > "for" field giving the envelope address as seen by that host.) > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 09 02:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoFn-0001HO-Im; Mon, 09 Oct 2006 02:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWoFm-0001HI-2Q for sip@ietf.org; Mon, 09 Oct 2006 02:04:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWoFj-0008CI-Oj for sip@ietf.org; Mon, 09 Oct 2006 02:04:42 -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 k9957e3m032288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Oct 2006 00:07:45 -0500 Message-ID: <4529E66D.9070307@softarmor.com> Date: Mon, 09 Oct 2006 01:04:29 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> <452692FA.5000709@cisco.com> In-Reply-To: <452692FA.5000709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List , Juha Heinanen , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Dean, > > I pretty much agree with you. > > Regarding response identity and your example: > > you called sip:7@myspeedial.example.net, and your server retargeted to > sip:brittney@spears.tv. So you are suggesting that your server should > notify you this happened, so that when you received response identity > you will not be surprised. > > Instead of this, how about having the proxy remain on the path and > insert a response identity for 7@myspeedial.example.net at least in > requests/responses that carry some other identity? Well, that sort of works, except that the call might be retargeted again by brittney's server, and I want to know about that too. > Regarding not wanting Brittney to know she's #7: what will you do about > the To header? Populate it with "Anonymous" like I always do with the useless To: header? I'm starting to think that putting anything meaningful in To is a recipe for heartburn. -- 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 Oct 09 04:01:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWq2F-0000qu-In; Mon, 09 Oct 2006 03:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWq2E-0000ql-SB for sip@ietf.org; Mon, 09 Oct 2006 03:58:50 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWq2D-0001MP-EF for sip@ietf.org; Mon, 09 Oct 2006 03:58:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k997wkFI018430; Mon, 9 Oct 2006 10:58:48 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 10:58:46 +0300 Received: from [172.21.36.67] ([172.21.36.67]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 9 Oct 2006 10:58:45 +0300 Message-ID: <452A0133.7050700@nokia.com> Date: Mon, 09 Oct 2006 10:58:43 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: "ext Schmidt, Christian" References: <72963DDDF17D7949ABD18DC5DA58E770016B02D3@MCHP7R5A.ww002.siemens.net> In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E770016B02D3@MCHP7R5A.ww002.siemens.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 07:58:46.0029 (UTC) FILETIME=[BF092BD0:01C6EB78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org Subject: [Sip] Re: New comment to draft-niemi-sip-subnot-etags-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Schmidt, Christian kirjoitti: > But in case of a subscription refresh (to extend the subscription time), > it could be done easier (e.g. without etag). > - Watcher send a SUBSCRIBE with "no additional notify needed" > - Presence server changes timeout of service and acknowledge it to the > watcher via 200 message. > - If there is any change of presenty information, this specific watcher > will be informed via NOTIFY message, independent from the subscription > refresh. > What do you think about? Is there another reason besides saving bytes for doing this instead of the Suppress-Notify-If-Match with the etag? > PS: The case fetching or polling of resource state should be described > in more details (e.g. messages). That's a good suggestion. I'm working on an update that will have examples as well, as those were TODO previously. ;) 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 Mon Oct 09 04:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqng-0005dt-C7; Mon, 09 Oct 2006 04:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqnf-0005do-N5 for sip@ietf.org; Mon, 09 Oct 2006 04:47:51 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWqne-0003Kg-9T for sip@ietf.org; Mon, 09 Oct 2006 04:47:51 -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 k998fAp02659; Mon, 9 Oct 2006 04:41: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] GRUU and Grid alternative Date: Mon, 9 Oct 2006 03:47:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110D26C20@zrc2hxm2.corp.nortel.com> In-Reply-To: <451A10FD.8040809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-Index: Acbh+WXA+peKsZUsQD627I7cuE9H0QJfcAQw From: "Brian Stucker" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Juha Heinanen , 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 Thinking about this again from a different angle... It seems to be that the crux of the proposal is to let the UAS know what the request URI was at the time the UAS's proxy got ahold of the request. A few thoughts...=20 First, what if the registrar wasn't integrated with the proxy? For instance, if the registrar is also a separate location server apart from the proxy, I think there's a problem. The proxy gets a request and needs to resolve the next hop. It sends the request to it's location server, which then sends back a 302 response to the request that the proxy uses to route upon. In this case, the location server has no idea what the requestor might do with the information, and the proxy has no idea it's contacted a registrar. The proxy needed a route, and the location server/registrar supplied them. How is the proxy to know not to rewrite the URI? The 302 response could have returned anything, not just a registered contact. Second, how does the proposal differ from simply having the UAS's proxy include a History-Info entry prior to swapping out the Request-URI with the UAS contact? The UAS can then look at the History-Info entry for the original URI. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, September 27, 2006 12:50 AM > To: IETF SIP List > Subject: [Sip] GRUU and Grid alternative >=20 > During our call on GRUU last week, there was a discussion on=20 > this issue that ekr raised, where he would like to see the=20 > grid usable outside of just gruu, i.e., with any AOR. >=20 > During the call, I made a suggestion for an alternative=20 > solution, and there was agreement amongst those on the call=20 > for the proposed approach. >=20 > The basic idea would be to remove the grid mechanism entirely=20 > from the gruu draft. Instead, a separate specification would=20 > be developed which would allow for loose routing to apply to=20 > user agents. So, consider a UA which registers. It would=20 > include a contact and a Supported header field with the value=20 > "ua-route". The registrar, assuming it understands this,=20 > notes that the UA supports UA loose routing and stores the=20 > contact. When an incoming call arrives for the AOR, rather=20 > than rewriting the R-URI with the registered contact, it=20 > pushes the registered contact into a Route header and leaves=20 > the R-URI alone (assuming the registered UA supports this mechanism). >=20 > How does this solve the grid problem? Lets say my AOR is=20 > sip:jdrosen@cisco.com. I, as a UA, can mint a URI with some=20 > arbitrary parameter, say sip:jdrosen@cisco.com;foo=3Dbaz, and=20 > hand it out to some correspondent. When a correspondent sends=20 > a request to that URI, it arrives at my home proxy. From=20 > there, since the R-URI is NOT rewritten, the entire URI,=20 > parameters and all, is passed to the UA. Thus, the UA knows=20 > the URI that was de-referenced. We wouldn't necessarily have=20 > to standardize a specific URI parameter, like grid, to carry=20 > the opaque data. >=20 > This trick solves a whole bunch of other problems too. It=20 > would eliminate the need for the IMS P-Called-Party-ID header=20 > field, and it would help clarify when a request is retargeted=20 > (change in R-URI) vs.=20 > when its just being delivered to the recipient (no change in R-URI). >=20 > Comments? >=20 > -Jonathan R. >=20 >=20 > --=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=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 Oct 09 08:51:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuXQ-0006Sx-Ki; Mon, 09 Oct 2006 08:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuXP-0006MQ-4X for sip@ietf.org; Mon, 09 Oct 2006 08:47:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWuXK-0002Hg-OZ for sip@ietf.org; Mon, 09 Oct 2006 08:47:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Oct 2006 08:47:15 -0400 X-IronPort-AV: i="4.09,282,1157342400"; d="scan'208"; a="106235691:sNHT61135110" 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 k99ClEH2011150; Mon, 9 Oct 2006 08:47: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 k99ClEYP009363; Mon, 9 Oct 2006 08:47:14 -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); Mon, 9 Oct 2006 08:46:52 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 08:46:51 -0400 Message-ID: <452A44BB.20807@cisco.com> Date: Mon, 09 Oct 2006 08:46:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Xia, Zhi Feng \(Bruce\)" Subject: Re: [Sip] Re: [Sip-implementors] Early media query References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 12:46:51.0508 (UTC) FILETIME=[FDFBF340:01C6EBA0] DKIM-Signature: a=rsa-sha1; q=dns; l=4290; t=1160398034; x=1161262034; 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]=20Re=3A=20[Sip-implementors]=20Early=20media=20query |To:=22Xia,=20Zhi=20Feng=20\(Bruce\)=22=20; X=v=3Dcisco.com=3B=20h=3DQeH9zbGVQEi+3OUeBGQ7WRhpyO8=3D; b=Qsbq8a7t/m9egxx2gSpRV/QpOP9TEpxYf/laQAZCLrngYPIzV3P4bPFJFIPyNVjX5Qbk1F/A vm/zLO17T4HDTDTDDswN3jbAZDQaMq5bZI+pvvUPXc9YzPkMq9MzLfWb; 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, Retesh Chadha X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Replaces approach is a possibility. But please explain why you think all the possibilities are invalid. Paul Xia, Zhi Feng (Bruce) wrote: > Given the restrictions in RFC, all four methods seem invalid. > > Before we can change the restrictions in the RFC, it looks to me using "replaces" is a better approach... > > How about this flow: > >> Caller Callee >> | | >> | | >> |(1) INVITE with offer | >> |----------------------------> | >> | | >> | | >> |(2) 183 with answer 1 | >> |<-------------------------------| >> | | >> | | >> |(3) PRACK | >> |----------------------------> | >> | | >> | | >> |(4) 200 PRACK | >> |<------------------------------| >> |(5) 200 OK | >> |<---------------------------- | >> | | >> |(6) ACK | >> |---------------------------->| >> | | >> |(7)Re-INVITE(replaces with new call id) >> |<----------------------------| >> | NOTIFY | > |-----------------------------> > |BYE(the original call id) > |-----------------------------> >> | | >> |(8) 200 OK with SDP | >> |---------------------------->| >> | | >> |(9) ACK | >> |---------------------------->| > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 2006?10?5? 22:52 > To: Darshan Bildikar > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; 'Retesh Chadha' > Subject: [Sip] Re: [Sip-implementors] Early media query > > > > > Darshan Bildikar wrote: >> I don't think that even Method 3 and 4 are OK because they will involve a >> change in the origin line parameter of the SDP and that is not allowed as >> per the RFC. > > Which RFC? > > I suport Crister's response. > > Paul > >> BTW, what was the rationale behind not allowing the origin line to change? >> It makes implementing apps like prepaid and CRBT very difficult. Could >> someone please throw some light on this? >> >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh Chadha >> Sent: Monday, October 02, 2006 5:46 PM >> To: Udit_Goyal@3com.com >> Cc: sip@ietf.org; sip-implementors@cs.columbia.edu >> Subject: Re: [Sip-implementors] Early media query >> >> Hi Udit >> Of all the methods you have specified, Method 1 and 2 are wrong as per >> the RFC which states that the sdp of all the provisional and 2xx >> response of INVITE should be same if they are present. >> >> Both Method 3 and 4 look fine, with method 4 being better because in >> that case 200 ok for INVITE is only sent when the final negotiation >> (call media) is done. >> >> Hope this helps. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 09 08:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWue6-0003fz-CF; Mon, 09 Oct 2006 08:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWue4-0003ft-HC for sip@ietf.org; Mon, 09 Oct 2006 08:54:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWue1-00061H-Fb for sip@ietf.org; Mon, 09 Oct 2006 08:54:12 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2006 05:53:56 -0700 X-IronPort-AV: i="4.09,282,1157353200"; d="scan'208"; a="1857028046:sNHT13369872330" 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 k99Cruqk023959; Mon, 9 Oct 2006 05:53:56 -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 k99CrUOf012202; Mon, 9 Oct 2006 05:53:56 -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); Mon, 9 Oct 2006 08:53:50 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 08:53:49 -0400 Message-ID: <452A465D.3090007@cisco.com> Date: Mon, 09 Oct 2006 08:53:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A082286@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A082286@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 12:53:49.0938 (UTC) FILETIME=[F7634D20:01C6EBA1] DKIM-Signature: a=rsa-sha1; q=dns; l=18867; t=1160398436; x=1161262436; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments); X=v=3Dcisco.com=3B=20h=3DxFpxC1XNdmtl1r/DEf+C1Z0YsQs=3D; b=Dbmc03bSBF+y/9cHHj3XmE8c2ZX3l6L/b+nUMGObiwo4VqXWNj9D73M5AmIkSOeikTRLw0++ f/CzjHxN1TIuTQZVDYCMSfhZ/nxDDuNtKD9A8hp6tbXykeb/XCgmLyWE; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Cc: Cullen Jennings , SIP , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Paul, > > Your message arrived just after I had submitted 02, so your comments are not > taken into account in that version. However, I felt it was useful to get 02 > out as a baseline for further discussion. Sure. I too am interested in seeing other inputs on this subject. > It seems the remaining issue is whether to add an explicit indication of > removal of the Identity header field by a verifier that has been unable to > verify the signature. Whilst this may make sense, I am concerned it starts > to go beyond the scope of connected-identity, so I would like other > opinions, especially from the chairs and from the authors of Identity. Rather than adding something to indicate that identity has been *removed* due to failure to verify, I am advocating adding something to indicate that verification has *succeeded*, while leaving the identity header in place. In this way, a downstream element may *either* trust the info added by the verifier or do its own verification of the identity header. Of course this is only significant if the verifier is doing work for downstream elements, and not for itself. Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 05 October 2006 16:29 >> To: Elwell, John >> Cc: Cullen Jennings; Jon Peterson; SIP >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >> draft-ietf-si p-connecte d-id entity-01 comments) >> >> >> >> Elwell, John wrote: >>> Paul, >>> >>> So your proposal is that the connected-identity RFC should >> update RFC 4474 >>> to somehow relax rules at a verifier. Correct? >> Yeah, I think so. >> >>> So the next question concerns the way in which these rules should be >>> relaxed. One problem with the verifier not being located at >> the UAS but at >>> some proxy is that the UAS might be configured always to >> trust identities >>> received in requests via the verifier's proxy if an >> Identity header field is >>> present, on the assumption that the signature has been >> checked by the >>> verifier. Therefore it sounds like the verifier, if it does >> not reject a >>> request with a bad signature, should remove the Identity >> header field (and >>> also Identity-Info) before forwarding the request towards >> the target. >> >> (I think I have seen someone propose combining the use of >> Identity and >> P-Asserted-Identity, though I don't recall the details, or >> which draft >> it was. So what I am about to say might bear no relationship to that.) >> >> I could see how Identity might be used between trust domains, while >> P-Asserted-Identity is used within a trust domain. In that case, a >> verifier might run at the entry point to a trust domain and if >> verification succeeds, insert a P-Asserted-Identity header with a >> corresponding identity. It then might, or might not, remove >> the Identity >> header. Recipients within the trust domain could then use >> P-Asserted-Identity as the source of identity info. (In this >> scenario, >> an identity header would only be added to requests when they >> leave the >> trust domain.) >> >> In this kind of environment, it is only necessary for the verifier to >> omit the P-Asserted-Identity header when verification fails. >> >>> Under what conditions should a verifier remove an Identity >> header field >>> rather than rejecting with 436/437/438? My inclination >> would be to leave it >>> as a matter of policy as far as the update to RFC 4474 is >> concerned, and >>> then make more precise statements concerning mid-dialog requests. >>> Alternatively the update to RFC 4474 could just relax the rules for >>> mid-dialog requests. I think there is some merit in >> relaxing the rules in >>> general, because otherwise there might be situations where >> a legitimate >>> caller cannot establish a call because an Authentication >> Service (outside >>> the UAC's control) is inserting an unverifiable signature (e.g., in >>> Identity-Info placing a URL that the Verifier cannot >> dereference for some >>> reason). >> What you say sounds reasonable to me. >> >> There is however some risk to having a verifier remove identity. The >> problem would be when there are potentially multiple verifiers that >> don't trust one another. If an early one removes the header, then it >> prevents a subsequent verifier from doing its own verification. >> >> This could come up if a request transits a domain on the way >> to another >> domain. Each domain may wish to do its own verification. >> >> That is an advantage to having the verifier add something to >> the request >> to indicate the result of its verification. >> >>> One consequence of the Verifier being separated from the >> UAS is that we >>> don't want to rely on stateful behaviour at the Verifier or >> its proxy (for >>> similar reasons that you cited for the Authentication >> Service earlier). So >>> for mid-dialog requests we would need to mandate, or at >> least recommend, >>> that 436/437/438 should not be sent. >> Right. >> >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 03 October 2006 01:44 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>> >>>> >>>> >>>> Elwell, John wrote: >>>>> Thinking further on this, perhaps there is a 4th way: >>>>> >>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>> 436, 437 or 438, >>>>> then it MUST NOT invoke the verifier for a subsequent request >>>> This assumes that the verifier is invoked by the UAS, and >> not by some >>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>> in a proxy >>>> before the UAS? This rule would forbid that, because it would >>>> cause that >>>> proxy to be call stateful. >>>> >>>> I think it would just be better to update the RFC, even >>>> though that is a >>>> bit more trouble than not to. >>>> >>>> Paul >>>> >>>>> on the same >>>>> dialog unless the From header field URI has changed, and in >>>> such cases >>>>> SHOULD NOT make use of the unverified connected-identity. >>>> Then a UAC, on >>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>> This would allow >>>>> business as usual on this dialog (but without the benefit >>>> of connected >>>>> identity, therefore no worse than at present). It avoids >>>> any change to RFC >>>>> 4474, because verification is optional anyway. >>>>> >>>>> Would this work? >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Elwell, John >>>>>> Sent: 26 September 2006 21:02 >>>>>> To: Cullen Jennings; Jon Peterson >>>>>> Cc: SIP; Paul Kyzivat >>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>> >>>>>> Cullen, Jon, >>>>>> >>>>>> In case you missed this (it wasn't addressed directly to >>>>>> you), I would greatly appreciate an opinion from each of you >>>>>> on this remaining issue in connected-identity. Just to >>>>>> summarise, RFC 4474 leaves it up to policy whether to return >>>>>> a 428 response if Identity is missing, but mandates the >>>>>> sending of a 436, 437 or 438 response for certain errors >>>>>> arising while verifying the signature. It seems that for mid >>>>>> dialog requests this behaviour could be harmful. What does >>>>>> the UAC for the mid dialog request do if it receives 436, 437 >>>>>> or 438? If the mid-dialog request was solely for the purpose >>>>>> of connected identity, it can give up and allow the call to >>>>>> continue as is. But if the request was for some other purpose >>>>>> (e.g., renegotiating the session because of hold, say, or >>>>>> session timer refresh), the UAC really wants it to work. For >>>>>> the normal case where the Authentication Service is at a >>>>>> proxy, not at the UAC, the UAC cannot force the >>>>>> Authentication Service to refrain from putting this >>>>>> unverifiable signature in the mid-dialog request, so any >>>>>> attempts to repeat the request would most likely be doomed to >>>>>> getting the same response. >>>>>> >>>>>> It seems there are three things we could do, none very >> attractive: >>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>> 4474 for a verifier by softening the requirements for sending >>>>>> 436, 437 and 438 in response to mid-dialog requests. But then >>>>>> a mid-dialog request from a rogue source would be accepted. >>>>>> 2. Say that the Authentication Service should omit the >>>>>> signing of mid-dialog requests if a previous attempt has >>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>> at the AS. >>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>> way and therefore things like session refresh and session >>>>>> renegotiation cannot be done, probably resulting in call >>>>>> failure. Sounds bad, but it is no different from an initial >>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>> AS inserts an Identity header that gets rejected with 436, >>>> 437 or 438. >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>> Sent: 22 September 2006 19:26 >>>>>>> To: Elwell, John >>>>>>> Cc: Cullen Jennings; SIP >>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>> >>>>>>> John, >>>>>>> >>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>> to say about >>>>>>> this. >>>>>>> >>>>>>> It is of some concern to me that a call might fail >>>> because of some >>>>>>> problem with the identity mechanism when the same call >> might have >>>>>>> succeeded in the absence of any identity. >>>>>>> >>>>>>> But possibly the solution to this is policy in the >>>>>>> implementation of the >>>>>>> verifier. What to do in the case of the conditions that >>>>>> lead to these >>>>>>> errors could be configurable in the verifier: either to >>>>>> generate the >>>>>>> error or simply to remove the identity info from the >>>>>> message. And the >>>>>>> policy could conceivably vary based on attributes of the >>>>>>> message, such >>>>>>> as whether it is in-dialog or not. >>>>>>> >>>>>>> Does it require a change to 4474 to permit that kind of policy? >>>>>>> >>>>>>> It would be annoying if the end user had no control over the >>>>>>> insertion >>>>>>> and verification of identity, and it resulted in calls >>>>>>> failing that the >>>>>>> user would like to permit. But I suppose that is itself >> a policy >>>>>>> decision. There are certainly enterprises that want to exert >>>>>>> that kind >>>>>>> of control over what users are permitted to do. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Elwell, John wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> I agree with most of your points, and on reflection I think >>>>>>> I agree that the >>>>>>>> solution has to be with the verifier. >>>>>>>> >>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>> 'Use Identity >>>>>>>> Header' response is concerned, because that is left to >>>>>>> policy, so we could >>>>>>>> say in connected-identity that policy should be to not >> send 428. >>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>> because RFC 4474 says >>>>>>>> that they MUST be sent under respective conditions. >>>>>>> Interestingly, though, >>>>>>>> there are other failure scenarios that can arise from the >>>>>>> procedures of >>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>> given on how to >>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>> authoritative for the >>>>>>>> domain. >>>>>>>> >>>>>>>> So one way to solve the present problem would be for the >>>>>>> connected-identity >>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>> of mid-dialog >>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>> 4474 as well as >>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>> to remove some of >>>>>>>> the security properties of RFC 4474. >>>>>>>> >>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>> responses will be sent, >>>>>>>> and failure to verify a signature will therefore result in >>>>>>> inability to >>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>> UPDATE or >>>>>>>> re-INVITE request was for some other purpose such as >>>>>>> session timer refresh >>>>>>>> or modifying the session, that action will fail. Then the >>>>>>> call will fail (in >>>>>>>> the case of inability to refresh the session timer) or >>>> the session >>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>> to caller ID >>>>>>>> verification failure in an INVITE request - it is >>>>>>> impossible to establish a >>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>> ability to rectify the >>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>> Authentication Service >>>>>>>> that puts a rogue Identity header field in every request. >>>>>>> In the connected >>>>>>>> identity case, the only difference is that the call is >>>>>>> already established >>>>>>>> but is likely to fail if verification fails. >>>>>>>> >>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>> wrong source, then >>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>> thing to do, and >>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>> indeed be the wrong >>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>> response codes can >>>>>>>> be received and will lead to failure. >>>>>>>> >>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>> sending a 428 and >>>>>>>> accept the consequences of other responses that the >>>>>>> verifier might send. >>>>>>>> John >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>> Sent: 22 September 2006 15:13 >>>>>>>>> To: Elwell, John >>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>> Subject: Re: [Sip] RE: >>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>> Elwell, John wrote: >>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>>>> When an Update is sent. Are there any conditions >> under which >>>>>>>>>>> it might >>>>>>>>>>> be rejected. Bad identity for example. I think that >>>>>>> might need a >>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>> an update >>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>> situation where it is >>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>> purposes such as >>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>> because connected >>>>>>>>>> identity fails. >>>>>>>>>> My proposed fix is as follows: >>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>> with 428 'Use >>>>>>>>>> Identity Header'. >>>>>>>>> I'm not sure about this. At the least I think this one needs >>>>>>>>> some clear >>>>>>>>> explanation of the SHOULD NOT - about the conditions when >>>>>>> it can be >>>>>>>>> violated. >>>>>>>>> >>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>> challenge on an >>>>>>>>> in-dialog request. In some cases it is the right thing to do. >>>>>>>>> >>>>>>>>> A UA that imposes such a requirement will be limited in what >>>>>>>>> it can do, >>>>>>>>> but that may still be right in some cases. >>>>>>>>> >>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>> Identity header field >>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>> dialog has resulted in >>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>> 438 'Invalid >>>>>>>>>> Identity Header'. >>>>>>>>> This requirement would force the authentication service to >>>>>>> be dialog >>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>> back into the >>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>> to tell the >>>>>>>>> authentication service not to act. >>>>>>>>> >>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>> results in one of >>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>> for the purpose of >>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>> identity there is >>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>> any further >>>>>>>>>> action". >>>>>>>>> This seems wrong to me. >>>>>>>>> >>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>> purpose of the >>>>>>>>> verifier is ultimately to drive an authorization decision. If >>>>>>>>> authorization would succeed in the absence of the >>>>>>> identity, then the >>>>>>>>> request should be permitted to continue as if the identity >>>>>>>>> was not present. >>>>>>>>> >>>>>>>>> Unfortunately this would seem to require a revision to 4474 >>>>>>>>> even though >>>>>>>>> the paint is hardly dry on it. >>>>>>>>> >>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>> cause the >>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>> *not* done, >>>>>>>>> then that need remains, which will still require a >>>>>> change to 4474. >>>>>>>>> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 09 11:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwev-0005EV-Mk; Mon, 09 Oct 2006 11:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWZ-00030Q-NF for sip@ietf.org; Mon, 09 Oct 2006 10:54:35 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwSm-00065Y-2A for sip@ietf.org; Mon, 09 Oct 2006 10:50:41 -0400 Received: from [192.168.2.102] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k99Drj8x002399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Oct 2006 08:53:45 -0500 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110D26C20@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437110D26C20@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DE4230C-5D66-4C87-AB14-243DA66C6468@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU and Grid alternative Date: Mon, 9 Oct 2006 09:50:30 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 9, 2006, at 3:47 AM, Brian Stucker wrote: > > First, what if the registrar wasn't integrated with the proxy? For > instance, if the registrar is also a separate location server apart > from > the proxy, I think there's a problem. The proxy gets a request and > needs > to resolve the next hop. It sends the request to it's location server, > which then sends back a 302 response to the request that the proxy > uses > to route upon. In this case, the location server has no idea what the > requestor might do with the information, and the proxy has no idea > it's > contacted a registrar. The proxy needed a route, and the location > server/registrar supplied them. How is the proxy to know not to > rewrite > the URI? The 302 response could have returned anything, not just a > registered contact. > The question you're asking: Is the operation of a proxy in processing a 302 response retargeting or rerouting? I suspect it is usually rerouting, and therefore the request URI would not change. I'm beginning to think that most of our proxy operations are rerouting, and we should only retarget when we're really intending to deliver the response to "somebody else". That said, it seems there are times when a redirect response from a proxy means "Contact your target at this alternate location" and times when it means "Please try a different target". We don't currently have a way to differentiate these cases in the current spec. Here's an off-the-wall proposal: We could say that a 302 always indicates a "retargeting" action and that, for the sake of preserving response identity (that is, eliminated unanticipated response identity), it SHOULD be returned to the originating UA rather than acted on by a proxy. We could also say that a 305 is always a rerouting action and MUST preserve the response identity, therefore it MAY be acted on by a proxy. Then we'd set up most "location servers" to send 305 instead of 302. > Second, how does the proposal differ from simply having the UAS's > proxy > include a History-Info entry prior to swapping out the Request-URI > with > the UAS contact? The UAS can then look at the History-Info entry > for the > original URI. Frankly, I don't expect SBCs to correctly pass History-Info any more than they correctly pass Via headers. I do however expect them to correctly pass request URIs. And with the idea of stacking "request parameters" in H-I or Via, we potentially get this awful situation where we have to figure out how to combine multiple parameters inserted in different places by different proxies. This doesn't occur, at least not the same way, if the only parameters examined by the UAS are those in the request URI. -- 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 Oct 09 11:27:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWx0M-0004BT-F1; Mon, 09 Oct 2006 11:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWx0L-0004BO-HE for sip@ietf.org; Mon, 09 Oct 2006 11:25:21 -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 1GWx0J-0002cs-S9 for sip@ietf.org; Mon, 09 Oct 2006 11:25:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2006 08:25:19 -0700 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k99FPJ49020320; Mon, 9 Oct 2006 08:25:19 -0700 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 k99FPIDM009958; Mon, 9 Oct 2006 11:25:18 -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); Mon, 9 Oct 2006 11:25:18 -0400 Received: from [161.44.55.73] ([161.44.55.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 11:25:18 -0400 Message-ID: <452A69DD.60602@cisco.com> Date: Mon, 09 Oct 2006 11:25:17 -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: Dean Willis Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> In-Reply-To: <452687A9.9050403@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 15:25:18.0080 (UTC) FILETIME=[2057B800:01C6EBB7] DKIM-Signature: a=rsa-sha1; q=dns; l=5674; t=1160407519; x=1161271519; c=relaxed/simple; s=sjdkim3002; 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]=20GRUU=20and=20Grid=20alternative; X=v=3Dcisco.com=3B=20h=3D5DtO8DGMv0uaAyOdOxaj3gFe+Iw=3D; b=Hkkk0d5aFWgToum8YDXHZHkF+lGvPwELh0G7ffiMg2cUoNNqbAFp/HYMNY0r4wpffCr05epF 7xMJQ2Zb9yJ4HNMWmlLFJucBaJhew1vGm4xuC4Tf8FrwWxRId1tjkGIs; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: IETF SIP List , Juha Heinanen , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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 big question here is how would we define 'retargeting' vs. 'routing' in a way that would make it easy for a proxy to figure out whether its rewriting the R-URI or adding a route header. One distinction related to your comments is that an action is retargeting if, had that operation not been done, the resulting UAS that is reached would have a connected party identity different than if it had been done. This definition doesn't help awfully much for name translations, for example the speed dial example you are giving. I'm inclined to agree that a speed dial operation is a retargeting, but its not obvious what the right definition of retargeting would be to help make this clear. -Jonathan R. Dean Willis wrote: > Juha Heinanen wrote: > >> jonathan, >> >> many sip phones on the market use as host part of r-uri their own >> domain. for example, if a phone in domain foo.bar makes call to local >> number 2345657, the phone will send out r-uri sip:234567@foo.bar. >> >> when that request hits foo.bar's proxy, it usually canonized the number >> that, for example, results in r-uri sip:+35640234567@foo.bar. then the >> proxy may make an enum query and find out that the r-uri needs to be >> re-written as sip:jh@tutpro.com. the proxy then re-writes r-uri >> accordingly and sends the request to tutpro.com's proxy. >> >> my question is, are you suggesting that when the request hit's >> tutpro.com's proxy, its request uri is still sip:234567@foo.bar and that >> route header contains sip:jh@tutpro.com? if so, what is the difference >> between r-uri and to uri? why do we need both? > > > I would say that tutpro.com's proxy is actually retargeting the request, > not routing the request. It can retarget the request because it is the > authoritative proxy for the domain-part. > > This is a "change of target" operation. > > Similar considerations apply for speed-dial services. > > Let's say I have a service that allows me to dial number@softarmor.com > and get that translated into a longer URI. For example, I might dial > "7@softarmor.com" to get routed to my girlfriend. Of course, I don't > want her thinking that she's #7 on my list -- I either want her to think > she's #1, or not thinking she's on a "list" at all. So I want my > speed-dial service to retarget the request, by which I mean I want it to > replace the request URI "sip:7@myspeedial.example.net" with the more AOR > "sip:hotchick29@escortservice.example.com" (or whatever the appropriate > AOR is). > > So, there are cases that demand request routing, and cases that demand > request retargeting. Any proxy can route, but (afaik) only a proxy > responsible for the request URI can retarget. > > One of the cases that we've done retargeting in that does NOT benefit > from it is the application of contact-routing, wherein a request sent to > an AOR is retargeted to a Contact" value. This should be a routing > operation -- we haven't changed the target, we've just routed the > request to a node that we believe can handle requests for that target > and that needs to know what the target was. > > Of course, we need to remain aware that any time we do a retargeting > operation at a proxy we complicate the "response identity" problem by > introducing a potentially unexpected respondent. > > I think the general rule of thumb is that once a request's URI has been > transformed into an AOR (and it might start out that way, or might not) > that most cases need routing and not retargeting for further handling. > > Let's clarify that a bit while thinking about response identity. > > Routing (as opposed to retargeting) to the Contact makes it fairly easy > for the UAS to figure out what identity to assert when responding to a > request, should we have a means to do that assertion. > > For example, I might have my phone registered for both > dean.willis@softarmor.com and deawilli@cisco.com. There's a cert for > each identity, copies of which are stored in the phone. But the certs > for these two identities are different, so the phone needs to know which > cert to apply on a response. It can do this by picking the cert based on > the request URI, if we did contact-routing according to Jonathan's > proposal. The "To:" header is not so useful, because it might contain > completely irrlevant information. > > But let's say I'm going on vacation for a few months (I'm thinking > European, as Americans don't actually have vacations like this) and wish > to forward my calls to Jonathan. Jonathan doesn't have my cert and can't > authenticate as me. So I probably want to retarget those requests to > him, not route them. We still have an unanticipated respondent -- > callers get Jonathan (and his cert), not me, but that's ok. > > I would like to see a proxy that retargets a request send something back > to the UAC (perhaps a reliable provisional) indicating that the call has > been retargeted and informing the caller of the anticipated new target > (potentially even provising authentication data for the new target) so > that we can eliminate the "unanticipated response" problem. But I think > we can do that as a separate body of work. > > -- > Dean > -- 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 Mon Oct 09 12:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxll-0007mK-SM; Mon, 09 Oct 2006 12:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxkQ-0006YS-30 for sip@ietf.org; Mon, 09 Oct 2006 12:12:58 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxXZ-0007GB-EG for sip@ietf.org; Mon, 09 Oct 2006 11:59:46 -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 k99FxVN22734; Mon, 9 Oct 2006 11:59: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] GRUU and Grid alternative Date: Mon, 9 Oct 2006 10:59:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F744@zrc2hxm2.corp.nortel.com> In-Reply-To: <8DE4230C-5D66-4C87-AB14-243DA66C6468@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-Index: Acbrsm44hE0JbXf4S8CZQHEOGLGnAwABwO2w From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, October 09, 2006 9:51 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Jonathan Rosenberg; IETF SIP List; Juha Heinanen;=20 > Dale.Worley@comcast.net > Subject: Re: [Sip] GRUU and Grid alternative >=20 >=20 > On Oct 9, 2006, at 3:47 AM, Brian Stucker wrote: >=20 >=20 > > > > First, what if the registrar wasn't integrated with the proxy? For=20 > > instance, if the registrar is also a separate location server apart=20 > > from the proxy, I think there's a problem. The proxy gets a request=20 > > and needs to resolve the next hop. It sends the request to it's=20 > > location server, which then sends back a 302 response to=20 > the request=20 > > that the proxy uses to route upon. In this case, the=20 > location server=20 > > has no idea what the requestor might do with the=20 > information, and the=20 > > proxy has no idea it's contacted a registrar. The proxy needed a=20 > > route, and the location server/registrar supplied them. How is the=20 > > proxy to know not to rewrite the URI? The 302 response could have=20 > > returned anything, not just a registered contact. > > >=20 > The question you're asking: Is the operation of a proxy in=20 > processing a 302 response retargeting or rerouting? >=20 > I suspect it is usually rerouting, and therefore the request=20 > URI would not change. I suspect that you're right, but it doesn't have to be. Further, the contact list could contain both endpoints to retarget to, and endpoints to reroute to. I don't think we can safely apply the same logic to an entire list of contacts and get a universally correct result. >=20 > I'm beginning to think that most of our proxy operations are=20 > rerouting, and we should only retarget when we're really=20 > intending to deliver the response to "somebody else". >=20 > That said, it seems there are times when a redirect response=20 > from a proxy means "Contact your target at this alternate=20 > location" and times when it means "Please try a different=20 > target". We don't currently have a way to differentiate these=20 > cases in the current spec. >=20 > Here's an off-the-wall proposal: >=20 > We could say that a 302 always indicates a "retargeting"=20 > action and that, for the sake of preserving response identity=20 > (that is, eliminated unanticipated response identity), it=20 > SHOULD be returned to the originating UA rather than acted on=20 > by a proxy. >=20 > We could also say that a 305 is always a rerouting action and=20 > MUST preserve the response identity, therefore it MAY be=20 > acted on by a proxy. >=20 > Then we'd set up most "location servers" to send 305 instead of 302. I doubt you can setup most location servers to send back a 305 instead of a 302. I would imagine the return code is hard-coded. Also, your response assumes that the contact list returned is homogenous: it's either all retargets, or all reroutes. I don't believe that the current specification has any such requirement on the 3xx contact lists, ie. they could be heterogeneous lists. >=20 > > Second, how does the proposal differ from simply having the UAS's=20 > > proxy include a History-Info entry prior to swapping out the=20 > > Request-URI with the UAS contact? The UAS can then look at the=20 > > History-Info entry for the original URI. >=20 > Frankly, I don't expect SBCs to correctly pass History-Info=20 > any more than they correctly pass Via headers. I do however=20 > expect them to correctly pass request URIs. Oh, why limit your imagination of Murphy's Special Law of the SBC: if can be mangled, it will be mangled. Seriously, that's the SBC's problem. Fortunately, unlike user agents, they are relatively limited in number and easier to fix when they're doing something bad. Designing for an SBC is like designing a protocol around someone who didn't read the RFC but instead Asked a Ninja how SIP worked (see www.askaninja.com if you've not already been there). I'd imagine most SBCs currently would only mangle an H-I out of random funness. I doubt that they would otherwise bother with them. >=20 > And with the idea of stacking "request parameters" in H-I or=20 > Via, we potentially get this awful situation where we have to=20 > figure out how to combine multiple parameters inserted in=20 > different places by different proxies. This doesn't occur, at=20 > least not the same way, if the only parameters examined by=20 > the UAS are those in the request URI. I thought the request-URI was going to get left alone from the originating UAC all the way to the UAS by the current proposal. What scenario are you talking about? Regards, 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 Mon Oct 09 12:27:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxwE-0001oe-HD; Mon, 09 Oct 2006 12:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxwD-0001oY-6r for sip@ietf.org; Mon, 09 Oct 2006 12:25:09 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxwB-0003wq-S9 for sip@ietf.org; Mon, 09 Oct 2006 12:25:09 -0400 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k99FSFxu003013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Oct 2006 10:28:16 -0500 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F744@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F744@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19D05E38-0BEF-4F9C-A948-87B663EF4A2F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU and Grid alternative Date: Mon, 9 Oct 2006 11:25:02 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 9, 2006, at 10:59 AM, Brian Stucker wrote: > > I suspect that you're right, but it doesn't have to be. Further, the > contact list could contain both endpoints to retarget to, and > endpoints > to reroute to. I don't think we can safely apply the same logic to an > entire list of contacts and get a universally correct result. > Two cliche responses: 1) Garbage in, garbage out 2) If it hurts, don't do it. Mixed response sets (unless each response is individually marked) are guaranteed to mess up the anticipated response identity namespace and turn the whole situation into a Mulligan Stew of unidentifiable ingredients. Don't use them. > > I doubt you can setup most location servers to send back a 305 instead > of a 302. I would imagine the return code is hard-coded. Also, your > response assumes that the contact list returned is homogenous: it's > either all retargets, or all reroutes. I don't believe that the > current > specification has any such requirement on the 3xx contact lists, ie. > they could be heterogeneous lists. > That would definitely be a change from current behavior. However, it would be a reasonably backward-compatible change, as it isn't going to make the situation any worse for existing already-broken systems. Furthermore, where redirect responses are processed by proxies, it has the advantage of not impacting UA specifications at all. Where redirect responses are NOT handled by proxies, this approach preserves 302 processing as it currently works, and could also be expected to work reasonably well with naive 305 handling in an existing UA. Yes, such a naive UA (as I understand it, some UAs treat 305 identically to 302) would end up retargeting when it could have simply rerouted, but the situation is still no worse than the current process. An alternative (alluded to above) is that each element in a redirection set could be tagged as a reroute or retarget. This might be less backward compatible. Or maybe not, as it might end up as current 302 processing does and just treat everything as a retarget unless the tag is understood by the UAC. > >> >> And with the idea of stacking "request parameters" in H-I or >> Via, we potentially get this awful situation where we have to >> figure out how to combine multiple parameters inserted in >> different places by different proxies. This doesn't occur, at >> least not the same way, if the only parameters examined by >> the UAS are those in the request URI. > > I thought the request-URI was going to get left alone from the > originating UAC all the way to the UAS by the current proposal. What > scenario are you talking about? > One variation of the proposal (and where H-I came into this thread) suggested continuing to rewrite the request URI in both rerouting and retargeting cases, but store the original request URI in a Via or H-I header field. The UAS would then work back up the Via or H-I stack to find the original parameters. I can readily imagine scenarios where several possibly conflicting parameters get inserted at different hops, thereby requiring the UAS to process through the whole Via or H- I stack and sort out the mess of parameters. I find this scenario unattractive. -- 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 Oct 09 12:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyLq-000602-QS; Mon, 09 Oct 2006 12:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyLp-0005zx-Fg for sip@ietf.org; Mon, 09 Oct 2006 12:51:37 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWyLo-00006Q-4u for sip@ietf.org; Mon, 09 Oct 2006 12:51:37 -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 k99Gitp26396; Mon, 9 Oct 2006 12:44: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] GRUU and Grid alternative Date: Mon, 9 Oct 2006 11:51:29 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F898@zrc2hxm2.corp.nortel.com> In-Reply-To: <19D05E38-0BEF-4F9C-A948-87B663EF4A2F@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-Index: Acbrv4PgZ9M2UrfITo+OEbW58McnTAAAcHbw From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, October 09, 2006 11:25 AM >=20 > > > > I suspect that you're right, but it doesn't have to be.=20 > Further, the=20 > > contact list could contain both endpoints to retarget to, and=20 > > endpoints to reroute to. I don't think we can safely apply the same=20 > > logic to an entire list of contacts and get a universally correct=20 > > result. > > >=20 > Two cliche responses: >=20 > 1) Garbage in, garbage out >=20 > 2) If it hurts, don't do it. >=20 > Mixed response sets (unless each response is individually=20 > marked) are guaranteed to mess up the anticipated response=20 > identity namespace and turn the whole situation into a=20 > Mulligan Stew of unidentifiable ingredients. Don't use them. But it didn't hurt until you started applying this new logic. I think that's what we call in the trade: not backwards compatible. I guess we can say: considered, not going to deal with it. However, given that an endpoint could have contacted a location server that isn't compliant to this spec, what I'm still struggling with is how the UA knows that what it got in the request-URI is what it thinks it is just because the last guy on the proxy chain put a route header in there. I've been bringing up various scenarios where there (to me) is a reasonable degree of "Yeah, that can happen and it'll change the request URI before we get to a proxy that supports the mechanism we're describing". I haven't gotten a satisfying response to these scenarios, and I do think it matters because these are scenarios that are going to break what you're trying to accomplish. They need to be handled deterministically and detectably in a backwards compatible manner because it's the older version element that's going to break you. > > > >> > >> And with the idea of stacking "request parameters" in H-I=20 > or Via, we=20 > >> potentially get this awful situation where we have to=20 > figure out how=20 > >> to combine multiple parameters inserted in different places by=20 > >> different proxies. This doesn't occur, at least not the=20 > same way, if=20 > >> the only parameters examined by the UAS are those in the=20 > request URI. > > > > I thought the request-URI was going to get left alone from the=20 > > originating UAC all the way to the UAS by the current=20 > proposal. What=20 > > scenario are you talking about? > > >=20 > One variation of the proposal (and where H-I came into this=20 > thread) suggested continuing to rewrite the request URI in=20 > both rerouting and retargeting cases, but store the original=20 > request URI in a Via or H-I header field. The UAS would then=20 > work back up the Via or H-I stack to find the original=20 > parameters. I can readily imagine scenarios where several=20 > possibly conflicting parameters get inserted at different=20 > hops, thereby requiring the UAS to process through the whole=20 > Via or H- I stack and sort out the mess of parameters. I find=20 > this scenario unattractive. I still don't understand. I thought we wanted the UAS to get the original request-URI specified by the UAC. Nothing bolted on or added/subtracted. The UAS should be able to simply look at the oldest H-I header and read off the captured request-URI value. I think that only one H-I header even needs to be captured by the first guy to try to change the request-URI. I'm still trying to figure out what the salient difference is here between this and the proposal, especially given that H-I seems a lot less likely to be broken by elements that are ignorant of the proposal. Regards, 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 Mon Oct 09 13:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyfG-0008Sq-RN; Mon, 09 Oct 2006 13:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyfF-0008S8-QW for sip@ietf.org; Mon, 09 Oct 2006 13:11:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWyfE-0003LO-Em for sip@ietf.org; Mon, 09 Oct 2006 13:11:41 -0400 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k99GDokG003385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Oct 2006 11:13:50 -0500 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F898@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F898@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92FCAFE3-4903-4175-8BF6-8222B3F34796@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] GRUU and Grid alternative Date: Mon, 9 Oct 2006 12:10:37 -0500 To: "Brian Stucker" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 9, 2006, at 11:51 AM, Brian Stucker wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, October 09, 2006 11:25 AM >> >>> >>> I suspect that you're right, but it doesn't have to be. >> Further, the >>> contact list could contain both endpoints to retarget to, and >>> endpoints to reroute to. I don't think we can safely apply the same >>> logic to an entire list of contacts and get a universally correct >>> result. >>> >> >> Two cliche responses: >> >> 1) Garbage in, garbage out >> >> 2) If it hurts, don't do it. >> >> Mixed response sets (unless each response is individually >> marked) are guaranteed to mess up the anticipated response >> identity namespace and turn the whole situation into a >> Mulligan Stew of unidentifiable ingredients. Don't use them. > > But it didn't hurt until you started applying this new logic. I think > that's what we call in the trade: not backwards compatible. > So you've solved response identity with the current logic? I don't think so. Given that the new logic's primary benefit is to fix the unanticipated response problem for "new logic" systems and make nothing worse when operating in "backward compatible" mode, I think we're ok. > I guess we can say: considered, not going to deal with it. However, > given that an endpoint could have contacted a location server that > isn't > compliant to this spec, what I'm still struggling with is how the UA > knows that what it got in the request-URI is what it thinks it is just > because the last guy on the proxy chain put a route header in there. > huh? > I've been bringing up various scenarios where there (to me) is a > reasonable degree of "Yeah, that can happen and it'll change the > request > URI before we get to a proxy that supports the mechanism we're > describing". I haven't gotten a satisfying response to these > scenarios, > and I do think it matters because these are scenarios that are > going to > break what you're trying to accomplish. They need to be handled > deterministically and detectably in a backwards compatible manner > because it's the older version element that's going to break you. > I think we're failing to communicate. At the very best and very west, you have a request URI delivered to a UAS. The UAS has to deal with that request URI. if there are parameters there that are meaningful, it has parameters to work from. If there aren't it doesn't. Systems cursed with current-edition broken retargeting just aren't going to be able to use the new mechanism, but that doesn't mean they work any worse (or any differently) from how they already work. My definition of "backward compatible" does NOT mean that the new features will work on old nodes. It means that the new features will not interfere with old nodes. >>> >>>> >>>> And with the idea of stacking "request parameters" in H-I >> or Via, we >>>> potentially get this awful situation where we have to >> figure out how >>>> to combine multiple parameters inserted in different places by >>>> different proxies. This doesn't occur, at least not the >> same way, if >>>> the only parameters examined by the UAS are those in the >> request URI. >>> >>> I thought the request-URI was going to get left alone from the >>> originating UAC all the way to the UAS by the current >> proposal. What >>> scenario are you talking about? >>> >> >> One variation of the proposal (and where H-I came into this >> thread) suggested continuing to rewrite the request URI in >> both rerouting and retargeting cases, but store the original >> request URI in a Via or H-I header field. The UAS would then >> work back up the Via or H-I stack to find the original >> parameters. I can readily imagine scenarios where several >> possibly conflicting parameters get inserted at different >> hops, thereby requiring the UAS to process through the whole >> Via or H- I stack and sort out the mess of parameters. I find >> this scenario unattractive. > > I still don't understand. I thought we wanted the UAS to get the > original request-URI specified by the UAC. Nothing bolted on or > added/subtracted. The UAS should be able to simply look at the oldest > H-I header and read off the captured request-URI value. I think that > only one H-I header even needs to be captured by the first guy to > try to > change the request-URI. What if the request URI got changed twice? This happens fairly frequently. Or what if there's another proxy between the proxy-that-does-contact- routing and the UAS, and that second proxy inserts an H-I for other purposes? What if there are 14 H-I records, all of which have stored parameters? > I'm still trying to figure out what the salient difference is here > between this and the proposal, especially given that H-I seems a lot > less likely to be broken by elements that are ignorant of the > proposal. H-I seems to me to be a lot less likely to produce a useful result. -- 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 Oct 09 13:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWytB-0007zU-8d; Mon, 09 Oct 2006 13:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWytA-0007zO-A7 for sip@ietf.org; Mon, 09 Oct 2006 13:26:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWyt8-0006H8-KS for sip@ietf.org; Mon, 09 Oct 2006 13:26:04 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2006 10:26:02 -0700 X-IronPort-AV: i="4.09,284,1157353200"; d="scan'208"; a="329555988:sNHT62750084" 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 k99HQ2Bc012477; Mon, 9 Oct 2006 10:26:02 -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 k99HPuOX027303; Mon, 9 Oct 2006 10:25:57 -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, 9 Oct 2006 13:25:40 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 13:25:40 -0400 Message-ID: <452A8614.7010509@cisco.com> Date: Mon, 09 Oct 2006 13:25:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] GRUU and Grid alternative References: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F898@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F898@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2006 17:25:40.0323 (UTC) FILETIME=[F1228B30:01C6EBC7] DKIM-Signature: a=rsa-sha1; q=dns; l=5963; t=1160414762; x=1161278762; c=relaxed/simple; s=sjdkim5002; 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=20Grid=20alternative; X=v=3Dcisco.com=3B=20h=3D37wdfzTcXxsKFn2cKwMMZsWTSx8=3D; b=XMMWkH+5fPv+eIhSU2vC5ueoHQXbUCz/HoAvSG6jgKh98osVYN/nsFtrv9vbEMdBeFUhqrmb ywEJdysEHyhfMozaV1yZu/WJNWqqFZev0nf/TFXdzn8n5tP80c4J1csA; Authentication-Results: sj-dkim-5.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: IETF SIP List , Juha Heinanen , 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 Regarding mixed retargetting and rerouting in the same 3xx: I don't see much of an incompatibility issue. Right now, when 302 is acted upon by proxy recursion it is always retargetting. So anybody expecting rerouting has been out of luck. If it was acted upon by the UAC, then it might be handled either as retargetting or rerouting, but the sender of the 302 can't predict which it will be. So at best it is currently handled as Dean proposes, and at worst it is handled in a totally unpredictable manner. Dean's proposal would improve the situation. In the case of 305 there are so many ambiguities and uncertainties about how it should work that in a practical sense it is unusuable. If this gave a well defined meaning to 305 it would again improve the overall situation. Incorporating 305 into this overall picture of distinguishing retargetting from rerouting is intriguing, and can help in making 305 usable. It does however raise some interesting issues. Suppose for now that a proxy for example.com is processing a request with R-URI of sip:alice@example.com, and there is one registered contact, for sip:alice.example.com;lr: - first the proxy appends 'Route: sip:alice.example.com;lr' after any existing route headers - if the proxy receives a 305 with 'Contact: ep.example.com;lr', what does that mean about how the next try is constructed? . is it by appending 'Route: sip:ep.example.com;lr;sip:alice.example.com;lr' to the original request? . or is it by appending only 'Route: sip:ep.example.com;lr' to the original request. I think both answers are reasonable under different circumstances. In the example given above, the first answer is probably the right one. But if the returned contact were 'sip:bob.example.com;lr' then the second answer would probably be correct. Paul Brian Stucker wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, October 09, 2006 11:25 AM >> >>> I suspect that you're right, but it doesn't have to be. >> Further, the >>> contact list could contain both endpoints to retarget to, and >>> endpoints to reroute to. I don't think we can safely apply the same >>> logic to an entire list of contacts and get a universally correct >>> result. >>> >> Two cliche responses: >> >> 1) Garbage in, garbage out >> >> 2) If it hurts, don't do it. >> >> Mixed response sets (unless each response is individually >> marked) are guaranteed to mess up the anticipated response >> identity namespace and turn the whole situation into a >> Mulligan Stew of unidentifiable ingredients. Don't use them. > > But it didn't hurt until you started applying this new logic. I think > that's what we call in the trade: not backwards compatible. > > I guess we can say: considered, not going to deal with it. However, > given that an endpoint could have contacted a location server that isn't > compliant to this spec, what I'm still struggling with is how the UA > knows that what it got in the request-URI is what it thinks it is just > because the last guy on the proxy chain put a route header in there. > > I've been bringing up various scenarios where there (to me) is a > reasonable degree of "Yeah, that can happen and it'll change the request > URI before we get to a proxy that supports the mechanism we're > describing". I haven't gotten a satisfying response to these scenarios, > and I do think it matters because these are scenarios that are going to > break what you're trying to accomplish. They need to be handled > deterministically and detectably in a backwards compatible manner > because it's the older version element that's going to break you. > >>>> And with the idea of stacking "request parameters" in H-I >> or Via, we >>>> potentially get this awful situation where we have to >> figure out how >>>> to combine multiple parameters inserted in different places by >>>> different proxies. This doesn't occur, at least not the >> same way, if >>>> the only parameters examined by the UAS are those in the >> request URI. >>> I thought the request-URI was going to get left alone from the >>> originating UAC all the way to the UAS by the current >> proposal. What >>> scenario are you talking about? >>> >> One variation of the proposal (and where H-I came into this >> thread) suggested continuing to rewrite the request URI in >> both rerouting and retargeting cases, but store the original >> request URI in a Via or H-I header field. The UAS would then >> work back up the Via or H-I stack to find the original >> parameters. I can readily imagine scenarios where several >> possibly conflicting parameters get inserted at different >> hops, thereby requiring the UAS to process through the whole >> Via or H- I stack and sort out the mess of parameters. I find >> this scenario unattractive. > > I still don't understand. I thought we wanted the UAS to get the > original request-URI specified by the UAC. Nothing bolted on or > added/subtracted. The UAS should be able to simply look at the oldest > H-I header and read off the captured request-URI value. I think that > only one H-I header even needs to be captured by the first guy to try to > change the request-URI. > > I'm still trying to figure out what the salient difference is here > between this and the proposal, especially given that H-I seems a lot > less likely to be broken by elements that are ignorant of the proposal. > > Regards, > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 09 13:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz6D-0006xx-8V; Mon, 09 Oct 2006 13:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz6B-0006t4-QO for sip@ietf.org; Mon, 09 Oct 2006 13:39:31 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWz6A-0000DL-I3 for sip@ietf.org; Mon, 09 Oct 2006 13:39:31 -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 k99HWop07893; Mon, 9 Oct 2006 13:32: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] GRUU and Grid alternative Date: Mon, 9 Oct 2006 12:39:24 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110D9F975@zrc2hxm2.corp.nortel.com> In-Reply-To: <92FCAFE3-4903-4175-8BF6-8222B3F34796@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] GRUU and Grid alternative Thread-Index: AcbrxgCGM1531ucET/u23PIXtUtslwAAmrZw From: "Brian Stucker" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Major snip. Resetting.=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, October 09, 2006 12:11 PM > > I think we're failing to communicate. Yes, but perhaps we're generating a lot of great text for a draft. Let me try again. Current proposal:=20 - Last hop adds a Route with the contact in it, leaves the request-URI alone. UAS inspects request-URI for parameters. Alternate proposal: - Last hop adds a H-I header, otherwise follows RFC-3261. UAS inspects H-I header for parameters. To me, it's a matter of what header type you're adding and how much you expect elements to do to support the mechanism. So why is one superior to the other? You are correct though, I've been using the wrong term by talking about backwards compatibility. I'm concerned about FORWARD compatibility: essentially if the new mechanism isn't deterministic and can't at least detect the presence of old nodes mucking about with the request-URI when we're not expecting them to, then it seems somewhat limited in value. If the proposal at least had a detection mechanism as to when the request-URI had been messed with I'd be a lot happier. Regards, 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 Mon Oct 09 21:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6ex-0002xh-TQ; Mon, 09 Oct 2006 21:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6ex-0002xZ-AO for sip@ietf.org; Mon, 09 Oct 2006 21:43:55 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX6es-0004hH-Qh for sip@ietf.org; Mon, 09 Oct 2006 21:43:55 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k9A1hnDo015751 for ; Mon, 9 Oct 2006 20:43:50 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Oct 2006 09:43:12 +0800 Received: from exch03.qd.lucent.com ([135.252.44.246]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Oct 2006 09:43:12 +0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [Sip] Re: [Sip-implementors] Early media query Date: Tue, 10 Oct 2006 09:43:06 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: [Sip-implementors] Early media query thread-index: AcbroPn4lQAhbeCvQJuXREyqphFQAQAZ89nQ From: "Xia, Zhi Feng \(Bruce\)" To: "Paul Kyzivat" , "Xia, Zhi Feng \(Bruce\)" X-OriginalArrivalTime: 10 Oct 2006 01:43:12.0272 (UTC) FILETIME=[72487900:01C6EC0D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, Retesh Chadha X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Quoting response from Retesh Chadha: >>Of all the methods you have specified, Method 1 and 2 are wrong as per >>the RFC which states that the sdp of all the provisional and 2xx >>response of INVITE should be same if they are present. Retesh I think you are quoting RFC3261 section 13.2.1? Please confirm. I = could not find the exact statement in the RFC. o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. Because method 3 and 4 requires an origin field change which conflicts = with RFC3264. See Darshan's comments. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 2006?10?9? 20:47 To: Xia, Zhi Feng (Bruce) Cc: Darshan Bildikar; sip@ietf.org; sip-implementors@cs.columbia.edu; = Retesh Chadha Subject: Re: [Sip] Re: [Sip-implementors] Early media query The Replaces approach is a possibility. But please explain why you think = all the possibilities are invalid. Paul Xia, Zhi Feng (Bruce) wrote: > Given the restrictions in RFC, all four methods seem invalid. >=20 > Before we can change the restrictions in the RFC, it looks to me = using "replaces" is a better approach... >=20 > How about this flow: >=20 >> Caller Callee >> | | >> | | >> |(1) INVITE with offer | >> |----------------------------> | >> | | >> | | >> |(2) 183 with answer 1 | >> |<-------------------------------| >> | | >> | | >> |(3) PRACK | >> |----------------------------> | >> | | >> | | >> |(4) 200 PRACK | >> |<------------------------------| >> |(5) 200 OK | >> |<---------------------------- | >> | | >> |(6) ACK | >> |---------------------------->| >> | | >> |(7)Re-INVITE(replaces with new call id) >> |<----------------------------| >> | NOTIFY | > |-----------------------------> > |BYE(the original call id) > |-----------------------------> >> | | >> |(8) 200 OK with SDP | >> |---------------------------->| >> | | >> |(9) ACK | >> |---------------------------->| >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 2006?10?5? 22:52 > To: Darshan Bildikar > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; 'Retesh Chadha' > Subject: [Sip] Re: [Sip-implementors] Early media query >=20 >=20 >=20 >=20 > Darshan Bildikar wrote: >> I don't think that even Method 3 and 4 are OK because they will = involve a >> change in the origin line parameter of the SDP and that is not = allowed as >> per the RFC.=20 >=20 > Which RFC? >=20 > I suport Crister's response. >=20 > Paul >=20 >> BTW, what was the rationale behind not allowing the origin line to = change? >> It makes implementing apps like prepaid and CRBT very difficult. = Could >> someone please throw some light on this? >> >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Retesh = Chadha >> Sent: Monday, October 02, 2006 5:46 PM >> To: Udit_Goyal@3com.com >> Cc: sip@ietf.org; sip-implementors@cs.columbia.edu >> Subject: Re: [Sip-implementors] Early media query >> >> Hi Udit >> Of all the methods you have specified, Method 1 and 2 are wrong as = per >> the RFC which states that the sdp of all the provisional and 2xx >> response of INVITE should be same if they are present. >> >> Both Method 3 and 4 look fine, with method 4 being better because in >> that case 200 ok for INVITE is only sent when the final negotiation >> (call media) is done. >> >> Hope this helps. >=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 Oct 10 01:30:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXA8Y-0003Eq-5P; Tue, 10 Oct 2006 01:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXA8X-00039s-0d for sip@ietf.org; Tue, 10 Oct 2006 01:26:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXA8S-00052M-MK for sip@ietf.org; Tue, 10 Oct 2006 01:26:40 -0400 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9A4TiNJ006147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Oct 2006 23:29:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Tue, 10 Oct 2006 00:26:28 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Sip] Agenda requests for our next meeting in San Diego X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org WARNING: WE MAY BE MEETING ON FRIDAY IN SAN DIEGO Meeting sixty-something is coming up in San Diego next month, and it's time to pull together an agenda. As usual, please send me requests for agenda slots, and of course I'll be "force feeding" a few slots for things my limited chair-wisdom tells me we'll need to talk about. I'll be putting together a request tracker on the softarmor site in the usual place, and will try and remember to send out a URL for that when it happens. We'll also be posting incremental agendas on the softarmor site an on the IETF tools page. Remember that meeting time is prioritized for the discussion of open issues relating to chartered work. It's not "my new draft presentation time" unless I'm feeling especially soft in the head and we accidentally have extra time or just need some relief between more heady topics. This time, we'll be trying to consolidate the time to give longer slots for critical topics (like GRUU!) and trying not to have 15- minute "presentation slots" if at all possible. I just turned 43, and I'm hoping to have this working group concluded by the time I retire, so let's try and stay on topic. If you have single-issue or (or maybe two issue) questions or announcements that you think can be resolved quickly, Keith and I will be happy to integrate your issues (and slides) into the "chair's" slide deck if they seem appropriate. If you'd like to make an agenda request, please send Keith and I a note including: Your name Your email address The topic The name of the main draft and any related drafts for the reading list How much time you THINK you need We'll also be asking that you get slides to us by the day before the meeting session. Please note that when last I looked, we had been booked for the Friday morning session, as well as another session somewhat earlier in the week, so make your travel plans accordingly. -- Dean, wearing chair hat, ceremonial robe, and staff of office. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 10 03:12:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBkg-0002I8-Rk; Tue, 10 Oct 2006 03:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXBkf-0002I1-A2 for sip@ietf.org; Tue, 10 Oct 2006 03:10:09 -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 1GXBka-0005yr-44 for sip@ietf.org; Tue, 10 Oct 2006 03:10:09 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6W00701RWVGR@siemenscomms.co.uk> for sip@ietf.org; Tue, 10 Oct 2006 08:10:07 +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 <0J6W00694RWV0O@siemenscomms.co.uk>; Tue, 10 Oct 2006 08:10:07 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9S48QB>; Tue, 10 Oct 2006 08:09:54 +0100 Content-return: allowed Date: Tue, 10 Oct 2006 08:09:54 +0100 From: "Elwell, John" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) To: Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A0DCB98@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: 5d188b91ff79eaa1be2a0e9635461d9a Cc: Cullen Jennings , SIP , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Dan Wing made a suggestion that P-Asserted-Identity would fulfil your requirement. I guess it would work like this. A Verifier not located at the UAS would attempt to verify the signature in the Identity header field. - Case A - verification succeeds. The Verifier inserts into the forwarded request a P-Asserted-Identity header field containing the verified URI (from the From header field) in the forwarded request. The Identity and Identity-Info header fields will still be present and available should another verifier be encountered downstream. - Case B - verification fails but request not rejected. The verifier is unable to verify (e.g., because it can't dereference the URL) but according to policy does not reject the request. It simply forwards the request as is. If there is a further verifier downstream, that too can attempt to verify the signature. - Case C - verification fails but request is rejected. The verifier is unable to verify (e.g., bad signature) and according to policy it rejects the request. A UAS that does not contain a verifier can simply use P-Asserted-Identity, if present. This seems to have some synergy with draft-rosenberg-sip-identity-coexistence. In fact the relaxation of rules concerning rejection by a verifier that is unable to verify a signature might be beneficial to that proposal. I will omit discussion of the mechanics of documentation until I see what reaction there is to the technical proposal. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 09 October 2006 13:54 > To: Elwell, John > Cc: Cullen Jennings; Jon Peterson; SIP > Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > draft-ietf-si p-connecte d-id entity-01 comments) > > > > Elwell, John wrote: > > Paul, > > > > Your message arrived just after I had submitted 02, so your > comments are not > > taken into account in that version. However, I felt it was > useful to get 02 > > out as a baseline for further discussion. > > Sure. I too am interested in seeing other inputs on this subject. > > > It seems the remaining issue is whether to add an explicit > indication of > > removal of the Identity header field by a verifier that has > been unable to > > verify the signature. Whilst this may make sense, I am > concerned it starts > > to go beyond the scope of connected-identity, so I would like other > > opinions, especially from the chairs and from the authors > of Identity. > > Rather than adding something to indicate that identity has been > *removed* due to failure to verify, I am advocating adding > something to > indicate that verification has *succeeded*, while leaving the > identity > header in place. In this way, a downstream element may *either* trust > the info added by the verifier or do its own verification of the > identity header. > > Of course this is only significant if the verifier is doing work for > downstream elements, and not for itself. > > Paul > > > John > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 05 October 2006 16:29 > >> To: Elwell, John > >> Cc: Cullen Jennings; Jon Peterson; SIP > >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >> draft-ietf-si p-connecte d-id entity-01 comments) > >> > >> > >> > >> Elwell, John wrote: > >>> Paul, > >>> > >>> So your proposal is that the connected-identity RFC should > >> update RFC 4474 > >>> to somehow relax rules at a verifier. Correct? > >> Yeah, I think so. > >> > >>> So the next question concerns the way in which these > rules should be > >>> relaxed. One problem with the verifier not being located at > >> the UAS but at > >>> some proxy is that the UAS might be configured always to > >> trust identities > >>> received in requests via the verifier's proxy if an > >> Identity header field is > >>> present, on the assumption that the signature has been > >> checked by the > >>> verifier. Therefore it sounds like the verifier, if it does > >> not reject a > >>> request with a bad signature, should remove the Identity > >> header field (and > >>> also Identity-Info) before forwarding the request towards > >> the target. > >> > >> (I think I have seen someone propose combining the use of > >> Identity and > >> P-Asserted-Identity, though I don't recall the details, or > >> which draft > >> it was. So what I am about to say might bear no > relationship to that.) > >> > >> I could see how Identity might be used between trust > domains, while > >> P-Asserted-Identity is used within a trust domain. In that case, a > >> verifier might run at the entry point to a trust domain and if > >> verification succeeds, insert a P-Asserted-Identity header with a > >> corresponding identity. It then might, or might not, remove > >> the Identity > >> header. Recipients within the trust domain could then use > >> P-Asserted-Identity as the source of identity info. (In this > >> scenario, > >> an identity header would only be added to requests when they > >> leave the > >> trust domain.) > >> > >> In this kind of environment, it is only necessary for the > verifier to > >> omit the P-Asserted-Identity header when verification fails. > >> > >>> Under what conditions should a verifier remove an Identity > >> header field > >>> rather than rejecting with 436/437/438? My inclination > >> would be to leave it > >>> as a matter of policy as far as the update to RFC 4474 is > >> concerned, and > >>> then make more precise statements concerning mid-dialog requests. > >>> Alternatively the update to RFC 4474 could just relax the > rules for > >>> mid-dialog requests. I think there is some merit in > >> relaxing the rules in > >>> general, because otherwise there might be situations where > >> a legitimate > >>> caller cannot establish a call because an Authentication > >> Service (outside > >>> the UAC's control) is inserting an unverifiable signature > (e.g., in > >>> Identity-Info placing a URL that the Verifier cannot > >> dereference for some > >>> reason). > >> What you say sounds reasonable to me. > >> > >> There is however some risk to having a verifier remove > identity. The > >> problem would be when there are potentially multiple > verifiers that > >> don't trust one another. If an early one removes the > header, then it > >> prevents a subsequent verifier from doing its own verification. > >> > >> This could come up if a request transits a domain on the way > >> to another > >> domain. Each domain may wish to do its own verification. > >> > >> That is an advantage to having the verifier add something to > >> the request > >> to indicate the result of its verification. > >> > >>> One consequence of the Verifier being separated from the > >> UAS is that we > >>> don't want to rely on stateful behaviour at the Verifier or > >> its proxy (for > >>> similar reasons that you cited for the Authentication > >> Service earlier). So > >>> for mid-dialog requests we would need to mandate, or at > >> least recommend, > >>> that 436/437/438 should not be sent. > >> Right. > >> > >> Paul > >> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 03 October 2006 01:44 > >>>> To: Elwell, John > >>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>> > >>>> > >>>> > >>>> Elwell, John wrote: > >>>>> Thinking further on this, perhaps there is a 4th way: > >>>>> > >>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>> 436, 437 or 438, > >>>>> then it MUST NOT invoke the verifier for a subsequent request > >>>> This assumes that the verifier is invoked by the UAS, and > >> not by some > >>>> proxy in front of the UAS. Isn't it valid to have a verifier > >>>> in a proxy > >>>> before the UAS? This rule would forbid that, because it would > >>>> cause that > >>>> proxy to be call stateful. > >>>> > >>>> I think it would just be better to update the RFC, even > >>>> though that is a > >>>> bit more trouble than not to. > >>>> > >>>> Paul > >>>> > >>>>> on the same > >>>>> dialog unless the From header field URI has changed, and in > >>>> such cases > >>>>> SHOULD NOT make use of the unverified connected-identity. > >>>> Then a UAC, on > >>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>> This would allow > >>>>> business as usual on this dialog (but without the benefit > >>>> of connected > >>>>> identity, therefore no worse than at present). It avoids > >>>> any change to RFC > >>>>> 4474, because verification is optional anyway. > >>>>> > >>>>> Would this work? > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Elwell, John > >>>>>> Sent: 26 September 2006 21:02 > >>>>>> To: Cullen Jennings; Jon Peterson > >>>>>> Cc: SIP; Paul Kyzivat > >>>>>> Subject: FW: Rejecting connected identity (was RE: > >>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>> > >>>>>> Cullen, Jon, > >>>>>> > >>>>>> In case you missed this (it wasn't addressed directly to > >>>>>> you), I would greatly appreciate an opinion from each of you > >>>>>> on this remaining issue in connected-identity. Just to > >>>>>> summarise, RFC 4474 leaves it up to policy whether to return > >>>>>> a 428 response if Identity is missing, but mandates the > >>>>>> sending of a 436, 437 or 438 response for certain errors > >>>>>> arising while verifying the signature. It seems that for mid > >>>>>> dialog requests this behaviour could be harmful. What does > >>>>>> the UAC for the mid dialog request do if it receives 436, 437 > >>>>>> or 438? If the mid-dialog request was solely for the purpose > >>>>>> of connected identity, it can give up and allow the call to > >>>>>> continue as is. But if the request was for some other purpose > >>>>>> (e.g., renegotiating the session because of hold, say, or > >>>>>> session timer refresh), the UAC really wants it to work. For > >>>>>> the normal case where the Authentication Service is at a > >>>>>> proxy, not at the UAC, the UAC cannot force the > >>>>>> Authentication Service to refrain from putting this > >>>>>> unverifiable signature in the mid-dialog request, so any > >>>>>> attempts to repeat the request would most likely be doomed to > >>>>>> getting the same response. > >>>>>> > >>>>>> It seems there are three things we could do, none very > >> attractive: > >>>>>> 1. Get connected-identity to modify the procedures of RFC > >>>>>> 4474 for a verifier by softening the requirements for sending > >>>>>> 436, 437 and 438 in response to mid-dialog requests. But then > >>>>>> a mid-dialog request from a rogue source would be accepted. > >>>>>> 2. Say that the Authentication Service should omit the > >>>>>> signing of mid-dialog requests if a previous attempt has > >>>>>> resulted in 436, 437 or 438. But this implies statefulness > >>>> at the AS. > >>>>>> 3. Accept the fact the mid-dialog requests can fail in this > >>>>>> way and therefore things like session refresh and session > >>>>>> renegotiation cannot be done, probably resulting in call > >>>>>> failure. Sounds bad, but it is no different from an initial > >>>>>> INVITE request, where there is nothing the UAC can do if the > >>>>>> AS inserts an Identity header that gets rejected with 436, > >>>> 437 or 438. > >>>>>> John > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>> Sent: 22 September 2006 19:26 > >>>>>>> To: Elwell, John > >>>>>>> Cc: Cullen Jennings; SIP > >>>>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>> > >>>>>>> John, > >>>>>>> > >>>>>>> I want to hear what others, especially Jon and Cullen, have > >>>>>>> to say about > >>>>>>> this. > >>>>>>> > >>>>>>> It is of some concern to me that a call might fail > >>>> because of some > >>>>>>> problem with the identity mechanism when the same call > >> might have > >>>>>>> succeeded in the absence of any identity. > >>>>>>> > >>>>>>> But possibly the solution to this is policy in the > >>>>>>> implementation of the > >>>>>>> verifier. What to do in the case of the conditions that > >>>>>> lead to these > >>>>>>> errors could be configurable in the verifier: either to > >>>>>> generate the > >>>>>>> error or simply to remove the identity info from the > >>>>>> message. And the > >>>>>>> policy could conceivably vary based on attributes of the > >>>>>>> message, such > >>>>>>> as whether it is in-dialog or not. > >>>>>>> > >>>>>>> Does it require a change to 4474 to permit that kind > of policy? > >>>>>>> > >>>>>>> It would be annoying if the end user had no control over the > >>>>>>> insertion > >>>>>>> and verification of identity, and it resulted in calls > >>>>>>> failing that the > >>>>>>> user would like to permit. But I suppose that is itself > >> a policy > >>>>>>> decision. There are certainly enterprises that want to exert > >>>>>>> that kind > >>>>>>> of control over what users are permitted to do. > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>> Elwell, John wrote: > >>>>>>>> Paul, > >>>>>>>> > >>>>>>>> I agree with most of your points, and on reflection I think > >>>>>>> I agree that the > >>>>>>>> solution has to be with the verifier. > >>>>>>>> > >>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 > >>>>>>> 'Use Identity > >>>>>>>> Header' response is concerned, because that is left to > >>>>>>> policy, so we could > >>>>>>>> say in connected-identity that policy should be to not > >> send 428. > >>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>> because RFC 4474 says > >>>>>>>> that they MUST be sent under respective conditions. > >>>>>>> Interestingly, though, > >>>>>>>> there are other failure scenarios that can arise from the > >>>>>>> procedures of > >>>>>>>> section 6 of RFC 4474 for which no normative statement is > >>>>>>> given on how to > >>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>> authoritative for the > >>>>>>>> domain. > >>>>>>>> > >>>>>>>> So one way to solve the present problem would be for the > >>>>>>> connected-identity > >>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case > >>>>>>> of mid-dialog > >>>>>>>> requests. I guess this would mean that it would update RFC > >>>>>>> 4474 as well as > >>>>>>>> updating RFC 3261. But I don't like this, because it seems > >>>>>>> to remove some of > >>>>>>>> the security properties of RFC 4474. > >>>>>>>> > >>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>> responses will be sent, > >>>>>>>> and failure to verify a signature will therefore result in > >>>>>>> inability to > >>>>>>>> process the UPDATE or re-INVITE request, and hence if the > >>>>>> UPDATE or > >>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>> session timer refresh > >>>>>>>> or modifying the session, that action will fail. Then the > >>>>>>> call will fail (in > >>>>>>>> the case of inability to refresh the session timer) or > >>>> the session > >>>>>>>> modification will fail. I guess this is somewhat analogous > >>>>>>> to caller ID > >>>>>>>> verification failure in an INVITE request - it is > >>>>>>> impossible to establish a > >>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>> ability to rectify the > >>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>> Authentication Service > >>>>>>>> that puts a rogue Identity header field in every request. > >>>>>>> In the connected > >>>>>>>> identity case, the only difference is that the call is > >>>>>>> already established > >>>>>>>> but is likely to fail if verification fails. > >>>>>>>> > >>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>> wrong source, then > >>>>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>>>> thing to do, and > >>>>>>>> overriding the verification procedures of RFC 4474 would > >>>>>>> indeed be the wrong > >>>>>>>> thing to do. So perhaps we just have to accept that these > >>>>>>> response codes can > >>>>>>>> be received and will lead to failure. > >>>>>>>> > >>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>> sending a 428 and > >>>>>>>> accept the consequences of other responses that the > >>>>>>> verifier might send. > >>>>>>>> John > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>>> Sent: 22 September 2006 15:13 > >>>>>>>>> To: Elwell, John > >>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>> Elwell, John wrote: > >>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>>>>>> When an Update is sent. Are there any conditions > >> under which > >>>>>>>>>>> it might > >>>>>>>>>>> be rejected. Bad identity for example. I think that > >>>>>>> might need a > >>>>>>>>>>> little discussion and also what the UA does when it sends > >>>>>>>>> an update > >>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>> situation where it is > >>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>> purposes such as > >>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>> because connected > >>>>>>>>>> identity fails. > >>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>>>>>>> with 428 'Use > >>>>>>>>>> Identity Header'. > >>>>>>>>> I'm not sure about this. At the least I think this > one needs > >>>>>>>>> some clear > >>>>>>>>> explanation of the SHOULD NOT - about the conditions when > >>>>>>> it can be > >>>>>>>>> violated. > >>>>>>>>> > >>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>> challenge on an > >>>>>>>>> in-dialog request. In some cases it is the right > thing to do. > >>>>>>>>> > >>>>>>>>> A UA that imposes such a requirement will be > limited in what > >>>>>>>>> it can do, > >>>>>>>>> but that may still be right in some cases. > >>>>>>>>> > >>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>> Identity header field > >>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>> dialog has resulted in > >>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or > >>>>>>>>> 438 'Invalid > >>>>>>>>>> Identity Header'. > >>>>>>>>> This requirement would force the authentication service to > >>>>>>> be dialog > >>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>> back into the > >>>>>>>>> sender of the request. This may require a way for the UAC > >>>>>>> to tell the > >>>>>>>>> authentication service not to act. > >>>>>>>>> > >>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>>>>>> results in one of > >>>>>>>>>> these responses if the mid-dialog request was not solely > >>>>>>>>> for the purpose of > >>>>>>>>>> connected identity. If solely for the purpose of connected > >>>>>>>>> identity there is > >>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take > >>>>>>> any further > >>>>>>>>>> action". > >>>>>>>>> This seems wrong to me. > >>>>>>>>> > >>>>>>>>> I think that the remedy to these is in the verifier. The > >>>>>>>>> purpose of the > >>>>>>>>> verifier is ultimately to drive an authorization > decision. If > >>>>>>>>> authorization would succeed in the absence of the > >>>>>>> identity, then the > >>>>>>>>> request should be permitted to continue as if the identity > >>>>>>>>> was not present. > >>>>>>>>> > >>>>>>>>> Unfortunately this would seem to require a revision to 4474 > >>>>>>>>> even though > >>>>>>>>> the paint is hardly dry on it. > >>>>>>>>> > >>>>>>>>> If this is done, then there is no need of a mechanism to > >>>>>> cause the > >>>>>>>>> authentication service *not* to authenticate. If this is > >>>>>>> *not* done, > >>>>>>>>> then that need remains, which will still require a > >>>>>> change to 4474. > >>>>>>>>> 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 > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 10 07:10:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXFRF-00041t-8N; Tue, 10 Oct 2006 07:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXFRD-00041g-M0 for sip@ietf.org; Tue, 10 Oct 2006 07:06:19 -0400 Received: from gate01.nexlink.ch ([80.86.198.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXFRC-0002aX-7Y for sip@ietf.org; Tue, 10 Oct 2006 07:06:19 -0400 Received: from MAIL03.NEXLINK.CH ([10.51.9.3]) by gate01.nexlink.ch (8.13.1/8.13.1) with ESMTP id k9AB6DTg022859; Tue, 10 Oct 2006 13:06:13 +0200 Message-Id: <200610101106.k9AB6DTg022859@gate01.nexlink.ch> MIME-Version: 1.0 From: =?ISO-8859-1?Q?Jo=EBl Repiquet?= To: sip@ietf.org Subject: Re: [Sip] WGLC: draft-ietf-sip-certs-01 Date: Tue, 10 Oct 2006 13:06:13 +0200 X-Uidl: 116047837374667435 X-Mailer: AtMail 4.3 X-Spam-Score: 1.8 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: fluffy@cisco.com, jon.peterson@neustar.biz X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joel.repiquet@tech-invite.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242070031==" Errors-To: sip-bounces@ietf.org --===============1242070031== Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Hi,

Regarding the "cert" draft, I have some remarks re= garding
the "Overview" and "Examples" sections, pl= us
some editorial notes.

Joël


In &quo= t;3. Overview":
---------------

There are in Bob's dom= ain 3 servers: Proxy, Auth and Cred.

Page 7, when:
 &n= bsp; "Alice decides that she wishes to discover Bob's
  = ; certificate, Alice's UA sends a SUBSCRIBE message to Bob's AOR.
&nbs= p;  The proxy in Bob's domain routes this to the credential server
   via an authorization service".

What do you m= ean by "authorization service"? conversely to the
"auth= entication service" and the "credential service" there is no=
clear standardization of it for SIP. Is it related
to some trait= -based mechanism? what would be its
role in this very case and why not= to have the proxy route
the SUBSCRIBE request directly to the credent= ial server?

Likewise, in the same paragraph:
   &= quot;The credential server returns a NOTIFY that contains Bob's public
   certificate in the body.  This is routed through an auth= entication
   service that signs that this message really ca= n validly claim to be
   from the AOR "sip:bob@example.= com".  Alice's UA receives the
   certificate and = can use it to encrypt a message to Bob."

According to the f= igure page 6, the "authentication service" is provided by
th= e same server as the "authorization service". Typically, it would= be provided -- as a
general service for the domain -- by the Proxy.Is not the Auth server superfluous, or is there any reason we need one?=


In "8. Examples":
----------------
In 8.1 we see that the authentication service is provided by the Creden= tial
server. I would add a "date" header since it is mandato= ry.


In 8.2, first paragraph:

   "= ;When Alice's UA wishes to publish Alice's public and private keys to
=    the credential service, it sends a PUBLISH request like the on= e
   below.  This must be sent over a TLS connection in= which the other
   end of the connection presents a certifi= cate that matches the
   credential service for Alice and di= gest challenges the request to
   authenticate her."
What do you mean by "that matches the credential service"= ;? the TLS server
certificate is not related to the credential service= .

In the PUBLISH request, I would add the header:
 &nb= sp; Event: credential


Editorial remarks:
------------= -----

In "1. Introduction" (2nd paragraph):
Repla= ce:
   In addition, this specification provides a which mech= anism allows SIP
by:
   In addition, this specification= provides a mechanism that allows SIP


In "4. UA Behav= ior with Certificates" (last paragraph):
Replace:
 &nbs= p; be valid and legal for that UA to send a 302 redirecting the call to
   Charlie.
by:
   be valid and legal for t= hat UA to send a 302 redirecting the call to
   Bob.

In "6.5. NOTIFY Bodies":
Replace:
  = ; other type.  The Content-Disposition MUST be set to "signal&quo= t;, as
   defined in as defined in [16].
by:
 = ;  other type.  The Content-Disposition MUST be set to "sign= al", as
   defined in [16].


In "1= 2. References": replace [2] and [19] by:

   [2]&n= bsp;  Peterson, J. and C. Jennings, "Enhancements for Authenticat= ed
         Identity Managemen= t in the Session Initiation Protocol (SIP)",
   &n= bsp;     RFC 4474, August 2006.

  = [19]  Roach, A., Campbell, B., and J. Rosenberg, "A Session Init= iation
         Protocol (SIP)= Event Notification Extension for Resource Lists",
  &n= bsp;      RFC 4662, August 2006.


=
--===============1242070031== 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 --===============1242070031==-- From sip-bounces@ietf.org Tue Oct 10 09:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHXC-00085q-7F; Tue, 10 Oct 2006 09:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXHXA-00085O-PC for sip@ietf.org; Tue, 10 Oct 2006 09:20:36 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXHX6-0001qw-Mi for sip@ietf.org; Tue, 10 Oct 2006 09:20:36 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2006 06:20:31 -0700 X-IronPort-AV: i="4.09,289,1157353200"; d="scan'208"; a="45493954:sNHT5096689646" 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 k9ADKUWk005563; Tue, 10 Oct 2006 09:20:30 -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 k9ADKUYJ000834; Tue, 10 Oct 2006 09:20:30 -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, 10 Oct 2006 09:20:30 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 09:20:29 -0400 Message-ID: <452B9E1C.4030804@cisco.com> Date: Tue, 10 Oct 2006 09:20:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 13:20:29.0921 (UTC) FILETIME=[DB771510:01C6EC6E] DKIM-Signature: a=rsa-sha1; q=dns; l=21841; t=1160486430; x=1161350430; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments) |To:=22Elwell,=20John=22=20; X=v=3Dcisco.com=3B=20h=3DxFpxC1XNdmtl1r/DEf+C1Z0YsQs=3D; b=oKiSXasPYLpM/DFWrHJzNrHh0FfXQrm+qMcSJsxtdGh1bWOH1YlidxDsTpgkvdRDhBu5TdH5 Fza6mzlFyvLRAaH2Avw9lV7d0XErOn2C168NKc0lL9M847JExNk99Eg9; 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: ceb20e3ccfd90d068e2ad6c8a4781b53 Cc: Cullen Jennings , SIP , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org John, What you outline below is exactly what I had in mind. Paul Elwell, John wrote: > Paul, > > Dan Wing made a suggestion that P-Asserted-Identity would fulfil your > requirement. I guess it would work like this. > > A Verifier not located at the UAS would attempt to verify the signature in > the Identity header field. > - Case A - verification succeeds. The Verifier inserts into the forwarded > request a P-Asserted-Identity header field containing the verified URI (from > the From header field) in the forwarded request. The Identity and > Identity-Info header fields will still be present and available should > another verifier be encountered downstream. > - Case B - verification fails but request not rejected. The verifier is > unable to verify (e.g., because it can't dereference the URL) but according > to policy does not reject the request. It simply forwards the request as is. > If there is a further verifier downstream, that too can attempt to verify > the signature. > - Case C - verification fails but request is rejected. The verifier is > unable to verify (e.g., bad signature) and according to policy it rejects > the request. > > A UAS that does not contain a verifier can simply use P-Asserted-Identity, > if present. > > This seems to have some synergy with > draft-rosenberg-sip-identity-coexistence. In fact the relaxation of rules > concerning rejection by a verifier that is unable to verify a signature > might be beneficial to that proposal. > > I will omit discussion of the mechanics of documentation until I see what > reaction there is to the technical proposal. > > John > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 09 October 2006 13:54 >> To: Elwell, John >> Cc: Cullen Jennings; Jon Peterson; SIP >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >> draft-ietf-si p-connecte d-id entity-01 comments) >> >> >> >> Elwell, John wrote: >>> Paul, >>> >>> Your message arrived just after I had submitted 02, so your >> comments are not >>> taken into account in that version. However, I felt it was >> useful to get 02 >>> out as a baseline for further discussion. >> Sure. I too am interested in seeing other inputs on this subject. >> >>> It seems the remaining issue is whether to add an explicit >> indication of >>> removal of the Identity header field by a verifier that has >> been unable to >>> verify the signature. Whilst this may make sense, I am >> concerned it starts >>> to go beyond the scope of connected-identity, so I would like other >>> opinions, especially from the chairs and from the authors >> of Identity. >> >> Rather than adding something to indicate that identity has been >> *removed* due to failure to verify, I am advocating adding >> something to >> indicate that verification has *succeeded*, while leaving the >> identity >> header in place. In this way, a downstream element may *either* trust >> the info added by the verifier or do its own verification of the >> identity header. >> >> Of course this is only significant if the verifier is doing work for >> downstream elements, and not for itself. >> >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 05 October 2006 16:29 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>> >>>> >>>> >>>> Elwell, John wrote: >>>>> Paul, >>>>> >>>>> So your proposal is that the connected-identity RFC should >>>> update RFC 4474 >>>>> to somehow relax rules at a verifier. Correct? >>>> Yeah, I think so. >>>> >>>>> So the next question concerns the way in which these >> rules should be >>>>> relaxed. One problem with the verifier not being located at >>>> the UAS but at >>>>> some proxy is that the UAS might be configured always to >>>> trust identities >>>>> received in requests via the verifier's proxy if an >>>> Identity header field is >>>>> present, on the assumption that the signature has been >>>> checked by the >>>>> verifier. Therefore it sounds like the verifier, if it does >>>> not reject a >>>>> request with a bad signature, should remove the Identity >>>> header field (and >>>>> also Identity-Info) before forwarding the request towards >>>> the target. >>>> >>>> (I think I have seen someone propose combining the use of >>>> Identity and >>>> P-Asserted-Identity, though I don't recall the details, or >>>> which draft >>>> it was. So what I am about to say might bear no >> relationship to that.) >>>> I could see how Identity might be used between trust >> domains, while >>>> P-Asserted-Identity is used within a trust domain. In that case, a >>>> verifier might run at the entry point to a trust domain and if >>>> verification succeeds, insert a P-Asserted-Identity header with a >>>> corresponding identity. It then might, or might not, remove >>>> the Identity >>>> header. Recipients within the trust domain could then use >>>> P-Asserted-Identity as the source of identity info. (In this >>>> scenario, >>>> an identity header would only be added to requests when they >>>> leave the >>>> trust domain.) >>>> >>>> In this kind of environment, it is only necessary for the >> verifier to >>>> omit the P-Asserted-Identity header when verification fails. >>>> >>>>> Under what conditions should a verifier remove an Identity >>>> header field >>>>> rather than rejecting with 436/437/438? My inclination >>>> would be to leave it >>>>> as a matter of policy as far as the update to RFC 4474 is >>>> concerned, and >>>>> then make more precise statements concerning mid-dialog requests. >>>>> Alternatively the update to RFC 4474 could just relax the >> rules for >>>>> mid-dialog requests. I think there is some merit in >>>> relaxing the rules in >>>>> general, because otherwise there might be situations where >>>> a legitimate >>>>> caller cannot establish a call because an Authentication >>>> Service (outside >>>>> the UAC's control) is inserting an unverifiable signature >> (e.g., in >>>>> Identity-Info placing a URL that the Verifier cannot >>>> dereference for some >>>>> reason). >>>> What you say sounds reasonable to me. >>>> >>>> There is however some risk to having a verifier remove >> identity. The >>>> problem would be when there are potentially multiple >> verifiers that >>>> don't trust one another. If an early one removes the >> header, then it >>>> prevents a subsequent verifier from doing its own verification. >>>> >>>> This could come up if a request transits a domain on the way >>>> to another >>>> domain. Each domain may wish to do its own verification. >>>> >>>> That is an advantage to having the verifier add something to >>>> the request >>>> to indicate the result of its verification. >>>> >>>>> One consequence of the Verifier being separated from the >>>> UAS is that we >>>>> don't want to rely on stateful behaviour at the Verifier or >>>> its proxy (for >>>>> similar reasons that you cited for the Authentication >>>> Service earlier). So >>>>> for mid-dialog requests we would need to mandate, or at >>>> least recommend, >>>>> that 436/437/438 should not be sent. >>>> Right. >>>> >>>> Paul >>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 03 October 2006 01:44 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>> >>>>>> >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>> >>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>> 436, 437 or 438, >>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>> This assumes that the verifier is invoked by the UAS, and >>>> not by some >>>>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>>>> in a proxy >>>>>> before the UAS? This rule would forbid that, because it would >>>>>> cause that >>>>>> proxy to be call stateful. >>>>>> >>>>>> I think it would just be better to update the RFC, even >>>>>> though that is a >>>>>> bit more trouble than not to. >>>>>> >>>>>> Paul >>>>>> >>>>>>> on the same >>>>>>> dialog unless the From header field URI has changed, and in >>>>>> such cases >>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>> Then a UAC, on >>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>> This would allow >>>>>>> business as usual on this dialog (but without the benefit >>>>>> of connected >>>>>>> identity, therefore no worse than at present). It avoids >>>>>> any change to RFC >>>>>>> 4474, because verification is optional anyway. >>>>>>> >>>>>>> Would this work? >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Elwell, John >>>>>>>> Sent: 26 September 2006 21:02 >>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>> >>>>>>>> Cullen, Jon, >>>>>>>> >>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>> you), I would greatly appreciate an opinion from each of you >>>>>>>> on this remaining issue in connected-identity. Just to >>>>>>>> summarise, RFC 4474 leaves it up to policy whether to return >>>>>>>> a 428 response if Identity is missing, but mandates the >>>>>>>> sending of a 436, 437 or 438 response for certain errors >>>>>>>> arising while verifying the signature. It seems that for mid >>>>>>>> dialog requests this behaviour could be harmful. What does >>>>>>>> the UAC for the mid dialog request do if it receives 436, 437 >>>>>>>> or 438? If the mid-dialog request was solely for the purpose >>>>>>>> of connected identity, it can give up and allow the call to >>>>>>>> continue as is. But if the request was for some other purpose >>>>>>>> (e.g., renegotiating the session because of hold, say, or >>>>>>>> session timer refresh), the UAC really wants it to work. For >>>>>>>> the normal case where the Authentication Service is at a >>>>>>>> proxy, not at the UAC, the UAC cannot force the >>>>>>>> Authentication Service to refrain from putting this >>>>>>>> unverifiable signature in the mid-dialog request, so any >>>>>>>> attempts to repeat the request would most likely be doomed to >>>>>>>> getting the same response. >>>>>>>> >>>>>>>> It seems there are three things we could do, none very >>>> attractive: >>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>> 4474 for a verifier by softening the requirements for sending >>>>>>>> 436, 437 and 438 in response to mid-dialog requests. But then >>>>>>>> a mid-dialog request from a rogue source would be accepted. >>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>>>> at the AS. >>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>> way and therefore things like session refresh and session >>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>>>> AS inserts an Identity header that gets rejected with 436, >>>>>> 437 or 438. >>>>>>>> John >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>> Sent: 22 September 2006 19:26 >>>>>>>>> To: Elwell, John >>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>> >>>>>>>>> John, >>>>>>>>> >>>>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>>>> to say about >>>>>>>>> this. >>>>>>>>> >>>>>>>>> It is of some concern to me that a call might fail >>>>>> because of some >>>>>>>>> problem with the identity mechanism when the same call >>>> might have >>>>>>>>> succeeded in the absence of any identity. >>>>>>>>> >>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>> implementation of the >>>>>>>>> verifier. What to do in the case of the conditions that >>>>>>>> lead to these >>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>> generate the >>>>>>>>> error or simply to remove the identity info from the >>>>>>>> message. And the >>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>> message, such >>>>>>>>> as whether it is in-dialog or not. >>>>>>>>> >>>>>>>>> Does it require a change to 4474 to permit that kind >> of policy? >>>>>>>>> It would be annoying if the end user had no control over the >>>>>>>>> insertion >>>>>>>>> and verification of identity, and it resulted in calls >>>>>>>>> failing that the >>>>>>>>> user would like to permit. But I suppose that is itself >>>> a policy >>>>>>>>> decision. There are certainly enterprises that want to exert >>>>>>>>> that kind >>>>>>>>> of control over what users are permitted to do. >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Elwell, John wrote: >>>>>>>>>> Paul, >>>>>>>>>> >>>>>>>>>> I agree with most of your points, and on reflection I think >>>>>>>>> I agree that the >>>>>>>>>> solution has to be with the verifier. >>>>>>>>>> >>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>> 'Use Identity >>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>> policy, so we could >>>>>>>>>> say in connected-identity that policy should be to not >>>> send 428. >>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>> because RFC 4474 says >>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>> Interestingly, though, >>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>> procedures of >>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>> given on how to >>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>> authoritative for the >>>>>>>>>> domain. >>>>>>>>>> >>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>> connected-identity >>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>> of mid-dialog >>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>> 4474 as well as >>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>> to remove some of >>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>> >>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>> responses will be sent, >>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>> inability to >>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>> UPDATE or >>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>> session timer refresh >>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>> call will fail (in >>>>>>>>>> the case of inability to refresh the session timer) or >>>>>> the session >>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>> to caller ID >>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>> impossible to establish a >>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>> ability to rectify the >>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>> Authentication Service >>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>> In the connected >>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>> already established >>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>> >>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>> wrong source, then >>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>> thing to do, and >>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>> indeed be the wrong >>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>> response codes can >>>>>>>>>> be received and will lead to failure. >>>>>>>>>> >>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>> sending a 428 and >>>>>>>>>> accept the consequences of other responses that the >>>>>>>>> verifier might send. >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>>>> Sent: 22 September 2006 15:13 >>>>>>>>>>> To: Elwell, John >>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>>>>>> When an Update is sent. Are there any conditions >>>> under which >>>>>>>>>>>>> it might >>>>>>>>>>>>> be rejected. Bad identity for example. I think that >>>>>>>>> might need a >>>>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>>>> an update >>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>> situation where it is >>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>> purposes such as >>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>> because connected >>>>>>>>>>>> identity fails. >>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>> with 428 'Use >>>>>>>>>>>> Identity Header'. >>>>>>>>>>> I'm not sure about this. At the least I think this >> one needs >>>>>>>>>>> some clear >>>>>>>>>>> explanation of the SHOULD NOT - about the conditions when >>>>>>>>> it can be >>>>>>>>>>> violated. >>>>>>>>>>> >>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>> challenge on an >>>>>>>>>>> in-dialog request. In some cases it is the right >> thing to do. >>>>>>>>>>> A UA that imposes such a requirement will be >> limited in what >>>>>>>>>>> it can do, >>>>>>>>>>> but that may still be right in some cases. >>>>>>>>>>> >>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>> Identity header field >>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>> dialog has resulted in >>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>>>> 438 'Invalid >>>>>>>>>>>> Identity Header'. >>>>>>>>>>> This requirement would force the authentication service to >>>>>>>>> be dialog >>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>> back into the >>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>> to tell the >>>>>>>>>>> authentication service not to act. >>>>>>>>>>> >>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>> results in one of >>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>> for the purpose of >>>>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>>>> identity there is >>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>> any further >>>>>>>>>>>> action". >>>>>>>>>>> This seems wrong to me. >>>>>>>>>>> >>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>> purpose of the >>>>>>>>>>> verifier is ultimately to drive an authorization >> decision. If >>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>> identity, then the >>>>>>>>>>> request should be permitted to continue as if the identity >>>>>>>>>>> was not present. >>>>>>>>>>> >>>>>>>>>>> Unfortunately this would seem to require a revision to 4474 >>>>>>>>>>> even though >>>>>>>>>>> the paint is hardly dry on it. >>>>>>>>>>> >>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>> cause the >>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>> *not* done, >>>>>>>>>>> then that need remains, which will still require a >>>>>>>> change to 4474. >>>>>>>>>>> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 10 15:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNCT-0007SS-ME; Tue, 10 Oct 2006 15:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNCR-0007SN-Ql for sip@ietf.org; Tue, 10 Oct 2006 15:23:35 -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 1GXNCO-0004Xj-Ja for sip@ietf.org; Tue, 10 Oct 2006 15:23:35 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6X00801PVAA6@siemenscomms.co.uk> for sip@ietf.org; Tue, 10 Oct 2006 20:23:35 +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 <0J6X0069LPVA2X@siemenscomms.co.uk>; Tue, 10 Oct 2006 20:23:34 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SVNY2>; Tue, 10 Oct 2006 20:23:22 +0100 Content-return: allowed Date: Tue, 10 Oct 2006 20:23:21 +0100 From: "Elwell, John" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) To: Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A11F092@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: 578029c71870398e30dc7af6a1ae528d Cc: Cullen Jennings , SIP , Jon Peterson , 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 Well, with just the three of us in agreement, I am not sure whether this is consensus. Anyway, let's assume the technical solution described below, where a verifier inserts P-Asserted-Identity in the forwarded request if verification is successful. Where would be the appropriate place to document this? I fear it would be stretching the scope of connected-identity too far to add it there. It might be better to put it into a separate document that updates RFC 4474. Such a document could in fact cover both updates to 4474: - insertion of PAI if verification successful; - leaving it up to policy whether to reject with 436/437/438 if error conditions occur. A separate document would have the advantage that it could apply to caller-identity as well as connected-identity. Perhaps draft-rosenberg-sip-identity-coexistence could fulfil that role. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 10 October 2006 14:20 > To: Elwell, John > Cc: Cullen Jennings; SIP; Dan Wing; Jon Peterson > Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > draft-ietf-si p-connecte d-id entity-01 comments) > > John, > > What you outline below is exactly what I had in mind. > > Paul > > Elwell, John wrote: > > Paul, > > > > Dan Wing made a suggestion that P-Asserted-Identity would > fulfil your > > requirement. I guess it would work like this. > > > > A Verifier not located at the UAS would attempt to verify > the signature in > > the Identity header field. > > - Case A - verification succeeds. The Verifier inserts into > the forwarded > > request a P-Asserted-Identity header field containing the > verified URI (from > > the From header field) in the forwarded request. The Identity and > > Identity-Info header fields will still be present and > available should > > another verifier be encountered downstream. > > - Case B - verification fails but request not rejected. The > verifier is > > unable to verify (e.g., because it can't dereference the > URL) but according > > to policy does not reject the request. It simply forwards > the request as is. > > If there is a further verifier downstream, that too can > attempt to verify > > the signature. > > - Case C - verification fails but request is rejected. The > verifier is > > unable to verify (e.g., bad signature) and according to > policy it rejects > > the request. > > > > A UAS that does not contain a verifier can simply use > P-Asserted-Identity, > > if present. > > > > This seems to have some synergy with > > draft-rosenberg-sip-identity-coexistence. In fact the > relaxation of rules > > concerning rejection by a verifier that is unable to verify > a signature > > might be beneficial to that proposal. > > > > I will omit discussion of the mechanics of documentation > until I see what > > reaction there is to the technical proposal. > > > > John > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 09 October 2006 13:54 > >> To: Elwell, John > >> Cc: Cullen Jennings; Jon Peterson; SIP > >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >> draft-ietf-si p-connecte d-id entity-01 comments) > >> > >> > >> > >> Elwell, John wrote: > >>> Paul, > >>> > >>> Your message arrived just after I had submitted 02, so your > >> comments are not > >>> taken into account in that version. However, I felt it was > >> useful to get 02 > >>> out as a baseline for further discussion. > >> Sure. I too am interested in seeing other inputs on this subject. > >> > >>> It seems the remaining issue is whether to add an explicit > >> indication of > >>> removal of the Identity header field by a verifier that has > >> been unable to > >>> verify the signature. Whilst this may make sense, I am > >> concerned it starts > >>> to go beyond the scope of connected-identity, so I would > like other > >>> opinions, especially from the chairs and from the authors > >> of Identity. > >> > >> Rather than adding something to indicate that identity has been > >> *removed* due to failure to verify, I am advocating adding > >> something to > >> indicate that verification has *succeeded*, while leaving the > >> identity > >> header in place. In this way, a downstream element may > *either* trust > >> the info added by the verifier or do its own verification of the > >> identity header. > >> > >> Of course this is only significant if the verifier is > doing work for > >> downstream elements, and not for itself. > >> > >> Paul > >> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 05 October 2006 16:29 > >>>> To: Elwell, John > >>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>> > >>>> > >>>> > >>>> Elwell, John wrote: > >>>>> Paul, > >>>>> > >>>>> So your proposal is that the connected-identity RFC should > >>>> update RFC 4474 > >>>>> to somehow relax rules at a verifier. Correct? > >>>> Yeah, I think so. > >>>> > >>>>> So the next question concerns the way in which these > >> rules should be > >>>>> relaxed. One problem with the verifier not being located at > >>>> the UAS but at > >>>>> some proxy is that the UAS might be configured always to > >>>> trust identities > >>>>> received in requests via the verifier's proxy if an > >>>> Identity header field is > >>>>> present, on the assumption that the signature has been > >>>> checked by the > >>>>> verifier. Therefore it sounds like the verifier, if it does > >>>> not reject a > >>>>> request with a bad signature, should remove the Identity > >>>> header field (and > >>>>> also Identity-Info) before forwarding the request towards > >>>> the target. > >>>> > >>>> (I think I have seen someone propose combining the use of > >>>> Identity and > >>>> P-Asserted-Identity, though I don't recall the details, or > >>>> which draft > >>>> it was. So what I am about to say might bear no > >> relationship to that.) > >>>> I could see how Identity might be used between trust > >> domains, while > >>>> P-Asserted-Identity is used within a trust domain. In > that case, a > >>>> verifier might run at the entry point to a trust domain and if > >>>> verification succeeds, insert a P-Asserted-Identity > header with a > >>>> corresponding identity. It then might, or might not, remove > >>>> the Identity > >>>> header. Recipients within the trust domain could then use > >>>> P-Asserted-Identity as the source of identity info. (In this > >>>> scenario, > >>>> an identity header would only be added to requests when they > >>>> leave the > >>>> trust domain.) > >>>> > >>>> In this kind of environment, it is only necessary for the > >> verifier to > >>>> omit the P-Asserted-Identity header when verification fails. > >>>> > >>>>> Under what conditions should a verifier remove an Identity > >>>> header field > >>>>> rather than rejecting with 436/437/438? My inclination > >>>> would be to leave it > >>>>> as a matter of policy as far as the update to RFC 4474 is > >>>> concerned, and > >>>>> then make more precise statements concerning mid-dialog > requests. > >>>>> Alternatively the update to RFC 4474 could just relax the > >> rules for > >>>>> mid-dialog requests. I think there is some merit in > >>>> relaxing the rules in > >>>>> general, because otherwise there might be situations where > >>>> a legitimate > >>>>> caller cannot establish a call because an Authentication > >>>> Service (outside > >>>>> the UAC's control) is inserting an unverifiable signature > >> (e.g., in > >>>>> Identity-Info placing a URL that the Verifier cannot > >>>> dereference for some > >>>>> reason). > >>>> What you say sounds reasonable to me. > >>>> > >>>> There is however some risk to having a verifier remove > >> identity. The > >>>> problem would be when there are potentially multiple > >> verifiers that > >>>> don't trust one another. If an early one removes the > >> header, then it > >>>> prevents a subsequent verifier from doing its own verification. > >>>> > >>>> This could come up if a request transits a domain on the way > >>>> to another > >>>> domain. Each domain may wish to do its own verification. > >>>> > >>>> That is an advantage to having the verifier add something to > >>>> the request > >>>> to indicate the result of its verification. > >>>> > >>>>> One consequence of the Verifier being separated from the > >>>> UAS is that we > >>>>> don't want to rely on stateful behaviour at the Verifier or > >>>> its proxy (for > >>>>> similar reasons that you cited for the Authentication > >>>> Service earlier). So > >>>>> for mid-dialog requests we would need to mandate, or at > >>>> least recommend, > >>>>> that 436/437/438 should not be sent. > >>>> Right. > >>>> > >>>> Paul > >>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: 03 October 2006 01:44 > >>>>>> To: Elwell, John > >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Elwell, John wrote: > >>>>>>> Thinking further on this, perhaps there is a 4th way: > >>>>>>> > >>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>>>> 436, 437 or 438, > >>>>>>> then it MUST NOT invoke the verifier for a subsequent request > >>>>>> This assumes that the verifier is invoked by the UAS, and > >>>> not by some > >>>>>> proxy in front of the UAS. Isn't it valid to have a verifier > >>>>>> in a proxy > >>>>>> before the UAS? This rule would forbid that, because it would > >>>>>> cause that > >>>>>> proxy to be call stateful. > >>>>>> > >>>>>> I think it would just be better to update the RFC, even > >>>>>> though that is a > >>>>>> bit more trouble than not to. > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>>> on the same > >>>>>>> dialog unless the From header field URI has changed, and in > >>>>>> such cases > >>>>>>> SHOULD NOT make use of the unverified connected-identity. > >>>>>> Then a UAC, on > >>>>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>>>> This would allow > >>>>>>> business as usual on this dialog (but without the benefit > >>>>>> of connected > >>>>>>> identity, therefore no worse than at present). It avoids > >>>>>> any change to RFC > >>>>>>> 4474, because verification is optional anyway. > >>>>>>> > >>>>>>> Would this work? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Elwell, John > >>>>>>>> Sent: 26 September 2006 21:02 > >>>>>>>> To: Cullen Jennings; Jon Peterson > >>>>>>>> Cc: SIP; Paul Kyzivat > >>>>>>>> Subject: FW: Rejecting connected identity (was RE: > >>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>> > >>>>>>>> Cullen, Jon, > >>>>>>>> > >>>>>>>> In case you missed this (it wasn't addressed directly to > >>>>>>>> you), I would greatly appreciate an opinion from each of you > >>>>>>>> on this remaining issue in connected-identity. Just to > >>>>>>>> summarise, RFC 4474 leaves it up to policy whether to return > >>>>>>>> a 428 response if Identity is missing, but mandates the > >>>>>>>> sending of a 436, 437 or 438 response for certain errors > >>>>>>>> arising while verifying the signature. It seems that for mid > >>>>>>>> dialog requests this behaviour could be harmful. What does > >>>>>>>> the UAC for the mid dialog request do if it receives > 436, 437 > >>>>>>>> or 438? If the mid-dialog request was solely for the purpose > >>>>>>>> of connected identity, it can give up and allow the call to > >>>>>>>> continue as is. But if the request was for some > other purpose > >>>>>>>> (e.g., renegotiating the session because of hold, say, or > >>>>>>>> session timer refresh), the UAC really wants it to work. For > >>>>>>>> the normal case where the Authentication Service is at a > >>>>>>>> proxy, not at the UAC, the UAC cannot force the > >>>>>>>> Authentication Service to refrain from putting this > >>>>>>>> unverifiable signature in the mid-dialog request, so any > >>>>>>>> attempts to repeat the request would most likely be > doomed to > >>>>>>>> getting the same response. > >>>>>>>> > >>>>>>>> It seems there are three things we could do, none very > >>>> attractive: > >>>>>>>> 1. Get connected-identity to modify the procedures of RFC > >>>>>>>> 4474 for a verifier by softening the requirements > for sending > >>>>>>>> 436, 437 and 438 in response to mid-dialog requests. > But then > >>>>>>>> a mid-dialog request from a rogue source would be accepted. > >>>>>>>> 2. Say that the Authentication Service should omit the > >>>>>>>> signing of mid-dialog requests if a previous attempt has > >>>>>>>> resulted in 436, 437 or 438. But this implies statefulness > >>>>>> at the AS. > >>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this > >>>>>>>> way and therefore things like session refresh and session > >>>>>>>> renegotiation cannot be done, probably resulting in call > >>>>>>>> failure. Sounds bad, but it is no different from an initial > >>>>>>>> INVITE request, where there is nothing the UAC can do if the > >>>>>>>> AS inserts an Identity header that gets rejected with 436, > >>>>>> 437 or 438. > >>>>>>>> John > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>>> Sent: 22 September 2006 19:26 > >>>>>>>>> To: Elwell, John > >>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>> > >>>>>>>>> John, > >>>>>>>>> > >>>>>>>>> I want to hear what others, especially Jon and Cullen, have > >>>>>>>>> to say about > >>>>>>>>> this. > >>>>>>>>> > >>>>>>>>> It is of some concern to me that a call might fail > >>>>>> because of some > >>>>>>>>> problem with the identity mechanism when the same call > >>>> might have > >>>>>>>>> succeeded in the absence of any identity. > >>>>>>>>> > >>>>>>>>> But possibly the solution to this is policy in the > >>>>>>>>> implementation of the > >>>>>>>>> verifier. What to do in the case of the conditions that > >>>>>>>> lead to these > >>>>>>>>> errors could be configurable in the verifier: either to > >>>>>>>> generate the > >>>>>>>>> error or simply to remove the identity info from the > >>>>>>>> message. And the > >>>>>>>>> policy could conceivably vary based on attributes of the > >>>>>>>>> message, such > >>>>>>>>> as whether it is in-dialog or not. > >>>>>>>>> > >>>>>>>>> Does it require a change to 4474 to permit that kind > >> of policy? > >>>>>>>>> It would be annoying if the end user had no control > over the > >>>>>>>>> insertion > >>>>>>>>> and verification of identity, and it resulted in calls > >>>>>>>>> failing that the > >>>>>>>>> user would like to permit. But I suppose that is itself > >>>> a policy > >>>>>>>>> decision. There are certainly enterprises that want > to exert > >>>>>>>>> that kind > >>>>>>>>> of control over what users are permitted to do. > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>> Elwell, John wrote: > >>>>>>>>>> Paul, > >>>>>>>>>> > >>>>>>>>>> I agree with most of your points, and on > reflection I think > >>>>>>>>> I agree that the > >>>>>>>>>> solution has to be with the verifier. > >>>>>>>>>> > >>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 > >>>>>>>>> 'Use Identity > >>>>>>>>>> Header' response is concerned, because that is left to > >>>>>>>>> policy, so we could > >>>>>>>>>> say in connected-identity that policy should be to not > >>>> send 428. > >>>>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>>>> because RFC 4474 says > >>>>>>>>>> that they MUST be sent under respective conditions. > >>>>>>>>> Interestingly, though, > >>>>>>>>>> there are other failure scenarios that can arise from the > >>>>>>>>> procedures of > >>>>>>>>>> section 6 of RFC 4474 for which no normative statement is > >>>>>>>>> given on how to > >>>>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>>>> authoritative for the > >>>>>>>>>> domain. > >>>>>>>>>> > >>>>>>>>>> So one way to solve the present problem would be for the > >>>>>>>>> connected-identity > >>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case > >>>>>>>>> of mid-dialog > >>>>>>>>>> requests. I guess this would mean that it would update RFC > >>>>>>>>> 4474 as well as > >>>>>>>>>> updating RFC 3261. But I don't like this, because it seems > >>>>>>>>> to remove some of > >>>>>>>>>> the security properties of RFC 4474. > >>>>>>>>>> > >>>>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>>>> responses will be sent, > >>>>>>>>>> and failure to verify a signature will therefore result in > >>>>>>>>> inability to > >>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the > >>>>>>>> UPDATE or > >>>>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>>>> session timer refresh > >>>>>>>>>> or modifying the session, that action will fail. Then the > >>>>>>>>> call will fail (in > >>>>>>>>>> the case of inability to refresh the session timer) or > >>>>>> the session > >>>>>>>>>> modification will fail. I guess this is somewhat analogous > >>>>>>>>> to caller ID > >>>>>>>>>> verification failure in an INVITE request - it is > >>>>>>>>> impossible to establish a > >>>>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>>>> ability to rectify the > >>>>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>>>> Authentication Service > >>>>>>>>>> that puts a rogue Identity header field in every request. > >>>>>>>>> In the connected > >>>>>>>>>> identity case, the only difference is that the call is > >>>>>>>>> already established > >>>>>>>>>> but is likely to fail if verification fails. > >>>>>>>>>> > >>>>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>>>> wrong source, then > >>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>>>>>> thing to do, and > >>>>>>>>>> overriding the verification procedures of RFC 4474 would > >>>>>>>>> indeed be the wrong > >>>>>>>>>> thing to do. So perhaps we just have to accept that these > >>>>>>>>> response codes can > >>>>>>>>>> be received and will lead to failure. > >>>>>>>>>> > >>>>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>>>> sending a 428 and > >>>>>>>>>> accept the consequences of other responses that the > >>>>>>>>> verifier might send. > >>>>>>>>>> John > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>>>>>>> Sent: 22 September 2006 15:13 > >>>>>>>>>>> To: Elwell, John > >>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>>>>>>>> When an Update is sent. Are there any conditions > >>>> under which > >>>>>>>>>>>>> it might > >>>>>>>>>>>>> be rejected. Bad identity for example. I think that > >>>>>>>>> might need a > >>>>>>>>>>>>> little discussion and also what the UA does > when it sends > >>>>>>>>>>> an update > >>>>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>>>> situation where it is > >>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>>>> purposes such as > >>>>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>>>> because connected > >>>>>>>>>>>> identity fails. > >>>>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>>>>>>>>> with 428 'Use > >>>>>>>>>>>> Identity Header'. > >>>>>>>>>>> I'm not sure about this. At the least I think this > >> one needs > >>>>>>>>>>> some clear > >>>>>>>>>>> explanation of the SHOULD NOT - about the conditions when > >>>>>>>>> it can be > >>>>>>>>>>> violated. > >>>>>>>>>>> > >>>>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>>>> challenge on an > >>>>>>>>>>> in-dialog request. In some cases it is the right > >> thing to do. > >>>>>>>>>>> A UA that imposes such a requirement will be > >> limited in what > >>>>>>>>>>> it can do, > >>>>>>>>>>> but that may still be right in some cases. > >>>>>>>>>>> > >>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>>>> Identity header field > >>>>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>>>> dialog has resulted in > >>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported > Certificate' or > >>>>>>>>>>> 438 'Invalid > >>>>>>>>>>>> Identity Header'. > >>>>>>>>>>> This requirement would force the authentication > service to > >>>>>>>>> be dialog > >>>>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>>>> back into the > >>>>>>>>>>> sender of the request. This may require a way for the UAC > >>>>>>>>> to tell the > >>>>>>>>>>> authentication service not to act. > >>>>>>>>>>> > >>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>>>>>>>> results in one of > >>>>>>>>>>>> these responses if the mid-dialog request was not solely > >>>>>>>>>>> for the purpose of > >>>>>>>>>>>> connected identity. If solely for the purpose of > connected > >>>>>>>>>>> identity there is > >>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take > >>>>>>>>> any further > >>>>>>>>>>>> action". > >>>>>>>>>>> This seems wrong to me. > >>>>>>>>>>> > >>>>>>>>>>> I think that the remedy to these is in the verifier. The > >>>>>>>>>>> purpose of the > >>>>>>>>>>> verifier is ultimately to drive an authorization > >> decision. If > >>>>>>>>>>> authorization would succeed in the absence of the > >>>>>>>>> identity, then the > >>>>>>>>>>> request should be permitted to continue as if the > identity > >>>>>>>>>>> was not present. > >>>>>>>>>>> > >>>>>>>>>>> Unfortunately this would seem to require a > revision to 4474 > >>>>>>>>>>> even though > >>>>>>>>>>> the paint is hardly dry on it. > >>>>>>>>>>> > >>>>>>>>>>> If this is done, then there is no need of a mechanism to > >>>>>>>> cause the > >>>>>>>>>>> authentication service *not* to authenticate. If this is > >>>>>>>>> *not* done, > >>>>>>>>>>> then that need remains, which will still require a > >>>>>>>> change to 4474. > >>>>>>>>>>> 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 10 16:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNy5-0005kZ-U9; Tue, 10 Oct 2006 16:12:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNy3-0005kT-4z for sip@ietf.org; Tue, 10 Oct 2006 16:12:47 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNy2-0001SC-8h for sip@ietf.org; Tue, 10 Oct 2006 16:12:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Oct 2006 16:12:46 -0400 X-IronPort-AV: i="4.09,291,1157342400"; d="scan'208"; a="106439308:sNHT101437132" 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 k9AKCkVD007276; Tue, 10 Oct 2006 16:12:46 -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 k9AKCjDM001047; Tue, 10 Oct 2006 16:12:45 -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, 10 Oct 2006 16:12:45 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 16:12:45 -0400 Message-ID: <452BFEBC.2050306@cisco.com> Date: Tue, 10 Oct 2006 16:12:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A11F092@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A11F092@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2006 20:12:45.0297 (UTC) FILETIME=[72E5EE10:01C6ECA8] DKIM-Signature: a=rsa-sha1; q=dns; l=25033; t=1160511166; x=1161375166; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments) |To:=22Elwell,=20John=22=20; X=v=3Dcisco.com=3B=20h=3DxFpxC1XNdmtl1r/DEf+C1Z0YsQs=3D; b=Kk3GavKpcaAwep5sVUUnuuBR0m853JWPQQtNZKl5F6xZFfZ4b37eTHVeErvjYYkzxqyuKQKP jIaHovqLCohNwvgkwZqw/7ILt7KwX3t4Cv4SdsROCvA4RwQ11IbcasE/; 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: a89bc6ca33b14646e47592488f7eaef6 Cc: Cullen Jennings , SIP , Jon Peterson , 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 Because of the connection to draft-rosenberg-sip-identity-coexistence, it would be good to get Jonathan's reaction to this. But I don't expect to get many attention units from him until gruu-11 and the new ice draft are done. It would also be good to get some input from Jon on this. He has very strong opinions on this kind of stuff. (I see he's already copied on this mail.) Paul Elwell, John wrote: > Well, with just the three of us in agreement, I am not sure whether this is > consensus. Anyway, let's assume the technical solution described below, > where a verifier inserts P-Asserted-Identity in the forwarded request if > verification is successful. Where would be the appropriate place to document > this? I fear it would be stretching the scope of connected-identity too far > to add it there. It might be better to put it into a separate document that > updates RFC 4474. Such a document could in fact cover both updates to 4474: > - insertion of PAI if verification successful; > - leaving it up to policy whether to reject with 436/437/438 if error > conditions occur. > > A separate document would have the advantage that it could apply to > caller-identity as well as connected-identity. Perhaps > draft-rosenberg-sip-identity-coexistence could fulfil that role. > > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 10 October 2006 14:20 >> To: Elwell, John >> Cc: Cullen Jennings; SIP; Dan Wing; Jon Peterson >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >> draft-ietf-si p-connecte d-id entity-01 comments) >> >> John, >> >> What you outline below is exactly what I had in mind. >> >> Paul >> >> Elwell, John wrote: >>> Paul, >>> >>> Dan Wing made a suggestion that P-Asserted-Identity would >> fulfil your >>> requirement. I guess it would work like this. >>> >>> A Verifier not located at the UAS would attempt to verify >> the signature in >>> the Identity header field. >>> - Case A - verification succeeds. The Verifier inserts into >> the forwarded >>> request a P-Asserted-Identity header field containing the >> verified URI (from >>> the From header field) in the forwarded request. The Identity and >>> Identity-Info header fields will still be present and >> available should >>> another verifier be encountered downstream. >>> - Case B - verification fails but request not rejected. The >> verifier is >>> unable to verify (e.g., because it can't dereference the >> URL) but according >>> to policy does not reject the request. It simply forwards >> the request as is. >>> If there is a further verifier downstream, that too can >> attempt to verify >>> the signature. >>> - Case C - verification fails but request is rejected. The >> verifier is >>> unable to verify (e.g., bad signature) and according to >> policy it rejects >>> the request. >>> >>> A UAS that does not contain a verifier can simply use >> P-Asserted-Identity, >>> if present. >>> >>> This seems to have some synergy with >>> draft-rosenberg-sip-identity-coexistence. In fact the >> relaxation of rules >>> concerning rejection by a verifier that is unable to verify >> a signature >>> might be beneficial to that proposal. >>> >>> I will omit discussion of the mechanics of documentation >> until I see what >>> reaction there is to the technical proposal. >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 09 October 2006 13:54 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>> >>>> >>>> >>>> Elwell, John wrote: >>>>> Paul, >>>>> >>>>> Your message arrived just after I had submitted 02, so your >>>> comments are not >>>>> taken into account in that version. However, I felt it was >>>> useful to get 02 >>>>> out as a baseline for further discussion. >>>> Sure. I too am interested in seeing other inputs on this subject. >>>> >>>>> It seems the remaining issue is whether to add an explicit >>>> indication of >>>>> removal of the Identity header field by a verifier that has >>>> been unable to >>>>> verify the signature. Whilst this may make sense, I am >>>> concerned it starts >>>>> to go beyond the scope of connected-identity, so I would >> like other >>>>> opinions, especially from the chairs and from the authors >>>> of Identity. >>>> >>>> Rather than adding something to indicate that identity has been >>>> *removed* due to failure to verify, I am advocating adding >>>> something to >>>> indicate that verification has *succeeded*, while leaving the >>>> identity >>>> header in place. In this way, a downstream element may >> *either* trust >>>> the info added by the verifier or do its own verification of the >>>> identity header. >>>> >>>> Of course this is only significant if the verifier is >> doing work for >>>> downstream elements, and not for itself. >>>> >>>> Paul >>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 05 October 2006 16:29 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>> >>>>>> >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Paul, >>>>>>> >>>>>>> So your proposal is that the connected-identity RFC should >>>>>> update RFC 4474 >>>>>>> to somehow relax rules at a verifier. Correct? >>>>>> Yeah, I think so. >>>>>> >>>>>>> So the next question concerns the way in which these >>>> rules should be >>>>>>> relaxed. One problem with the verifier not being located at >>>>>> the UAS but at >>>>>>> some proxy is that the UAS might be configured always to >>>>>> trust identities >>>>>>> received in requests via the verifier's proxy if an >>>>>> Identity header field is >>>>>>> present, on the assumption that the signature has been >>>>>> checked by the >>>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>>> not reject a >>>>>>> request with a bad signature, should remove the Identity >>>>>> header field (and >>>>>>> also Identity-Info) before forwarding the request towards >>>>>> the target. >>>>>> >>>>>> (I think I have seen someone propose combining the use of >>>>>> Identity and >>>>>> P-Asserted-Identity, though I don't recall the details, or >>>>>> which draft >>>>>> it was. So what I am about to say might bear no >>>> relationship to that.) >>>>>> I could see how Identity might be used between trust >>>> domains, while >>>>>> P-Asserted-Identity is used within a trust domain. In >> that case, a >>>>>> verifier might run at the entry point to a trust domain and if >>>>>> verification succeeds, insert a P-Asserted-Identity >> header with a >>>>>> corresponding identity. It then might, or might not, remove >>>>>> the Identity >>>>>> header. Recipients within the trust domain could then use >>>>>> P-Asserted-Identity as the source of identity info. (In this >>>>>> scenario, >>>>>> an identity header would only be added to requests when they >>>>>> leave the >>>>>> trust domain.) >>>>>> >>>>>> In this kind of environment, it is only necessary for the >>>> verifier to >>>>>> omit the P-Asserted-Identity header when verification fails. >>>>>> >>>>>>> Under what conditions should a verifier remove an Identity >>>>>> header field >>>>>>> rather than rejecting with 436/437/438? My inclination >>>>>> would be to leave it >>>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>>> concerned, and >>>>>>> then make more precise statements concerning mid-dialog >> requests. >>>>>>> Alternatively the update to RFC 4474 could just relax the >>>> rules for >>>>>>> mid-dialog requests. I think there is some merit in >>>>>> relaxing the rules in >>>>>>> general, because otherwise there might be situations where >>>>>> a legitimate >>>>>>> caller cannot establish a call because an Authentication >>>>>> Service (outside >>>>>>> the UAC's control) is inserting an unverifiable signature >>>> (e.g., in >>>>>>> Identity-Info placing a URL that the Verifier cannot >>>>>> dereference for some >>>>>>> reason). >>>>>> What you say sounds reasonable to me. >>>>>> >>>>>> There is however some risk to having a verifier remove >>>> identity. The >>>>>> problem would be when there are potentially multiple >>>> verifiers that >>>>>> don't trust one another. If an early one removes the >>>> header, then it >>>>>> prevents a subsequent verifier from doing its own verification. >>>>>> >>>>>> This could come up if a request transits a domain on the way >>>>>> to another >>>>>> domain. Each domain may wish to do its own verification. >>>>>> >>>>>> That is an advantage to having the verifier add something to >>>>>> the request >>>>>> to indicate the result of its verification. >>>>>> >>>>>>> One consequence of the Verifier being separated from the >>>>>> UAS is that we >>>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>>> its proxy (for >>>>>>> similar reasons that you cited for the Authentication >>>>>> Service earlier). So >>>>>>> for mid-dialog requests we would need to mandate, or at >>>>>> least recommend, >>>>>>> that 436/437/438 should not be sent. >>>>>> Right. >>>>>> >>>>>> Paul >>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Sent: 03 October 2006 01:44 >>>>>>>> To: Elwell, John >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Elwell, John wrote: >>>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>>> >>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>>> 436, 437 or 438, >>>>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>>> not by some >>>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>>>>>> in a proxy >>>>>>>> before the UAS? This rule would forbid that, because it would >>>>>>>> cause that >>>>>>>> proxy to be call stateful. >>>>>>>> >>>>>>>> I think it would just be better to update the RFC, even >>>>>>>> though that is a >>>>>>>> bit more trouble than not to. >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> on the same >>>>>>>>> dialog unless the From header field URI has changed, and in >>>>>>>> such cases >>>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>>> Then a UAC, on >>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>>> This would allow >>>>>>>>> business as usual on this dialog (but without the benefit >>>>>>>> of connected >>>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>>> any change to RFC >>>>>>>>> 4474, because verification is optional anyway. >>>>>>>>> >>>>>>>>> Would this work? >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Elwell, John >>>>>>>>>> Sent: 26 September 2006 21:02 >>>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>> >>>>>>>>>> Cullen, Jon, >>>>>>>>>> >>>>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>>>> you), I would greatly appreciate an opinion from each of you >>>>>>>>>> on this remaining issue in connected-identity. Just to >>>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to return >>>>>>>>>> a 428 response if Identity is missing, but mandates the >>>>>>>>>> sending of a 436, 437 or 438 response for certain errors >>>>>>>>>> arising while verifying the signature. It seems that for mid >>>>>>>>>> dialog requests this behaviour could be harmful. What does >>>>>>>>>> the UAC for the mid dialog request do if it receives >> 436, 437 >>>>>>>>>> or 438? If the mid-dialog request was solely for the purpose >>>>>>>>>> of connected identity, it can give up and allow the call to >>>>>>>>>> continue as is. But if the request was for some >> other purpose >>>>>>>>>> (e.g., renegotiating the session because of hold, say, or >>>>>>>>>> session timer refresh), the UAC really wants it to work. For >>>>>>>>>> the normal case where the Authentication Service is at a >>>>>>>>>> proxy, not at the UAC, the UAC cannot force the >>>>>>>>>> Authentication Service to refrain from putting this >>>>>>>>>> unverifiable signature in the mid-dialog request, so any >>>>>>>>>> attempts to repeat the request would most likely be >> doomed to >>>>>>>>>> getting the same response. >>>>>>>>>> >>>>>>>>>> It seems there are three things we could do, none very >>>>>> attractive: >>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>>>> 4474 for a verifier by softening the requirements >> for sending >>>>>>>>>> 436, 437 and 438 in response to mid-dialog requests. >> But then >>>>>>>>>> a mid-dialog request from a rogue source would be accepted. >>>>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>>>>>> at the AS. >>>>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>>>> way and therefore things like session refresh and session >>>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>>>>>> AS inserts an Identity header that gets rejected with 436, >>>>>>>> 437 or 438. >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>>>> Sent: 22 September 2006 19:26 >>>>>>>>>>> To: Elwell, John >>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>>>>>> to say about >>>>>>>>>>> this. >>>>>>>>>>> >>>>>>>>>>> It is of some concern to me that a call might fail >>>>>>>> because of some >>>>>>>>>>> problem with the identity mechanism when the same call >>>>>> might have >>>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>>> >>>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>>> implementation of the >>>>>>>>>>> verifier. What to do in the case of the conditions that >>>>>>>>>> lead to these >>>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>>> generate the >>>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>>> message. And the >>>>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>>>> message, such >>>>>>>>>>> as whether it is in-dialog or not. >>>>>>>>>>> >>>>>>>>>>> Does it require a change to 4474 to permit that kind >>>> of policy? >>>>>>>>>>> It would be annoying if the end user had no control >> over the >>>>>>>>>>> insertion >>>>>>>>>>> and verification of identity, and it resulted in calls >>>>>>>>>>> failing that the >>>>>>>>>>> user would like to permit. But I suppose that is itself >>>>>> a policy >>>>>>>>>>> decision. There are certainly enterprises that want >> to exert >>>>>>>>>>> that kind >>>>>>>>>>> of control over what users are permitted to do. >>>>>>>>>>> >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>> Paul, >>>>>>>>>>>> >>>>>>>>>>>> I agree with most of your points, and on >> reflection I think >>>>>>>>>>> I agree that the >>>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>>> >>>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>>>> 'Use Identity >>>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>>> policy, so we could >>>>>>>>>>>> say in connected-identity that policy should be to not >>>>>> send 428. >>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>>> because RFC 4474 says >>>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>>> Interestingly, though, >>>>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>>>> procedures of >>>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>>>> given on how to >>>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>>> authoritative for the >>>>>>>>>>>> domain. >>>>>>>>>>>> >>>>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>>>> connected-identity >>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>>>> of mid-dialog >>>>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>>>> 4474 as well as >>>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>>>> to remove some of >>>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>>> >>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>>> responses will be sent, >>>>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>>>> inability to >>>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>>>> UPDATE or >>>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>>> session timer refresh >>>>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>>>> call will fail (in >>>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>>> the session >>>>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>>>> to caller ID >>>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>>> impossible to establish a >>>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>>> ability to rectify the >>>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>>> Authentication Service >>>>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>>>> In the connected >>>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>>> already established >>>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>>> >>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>>> wrong source, then >>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>>>> thing to do, and >>>>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>>>> indeed be the wrong >>>>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>>>> response codes can >>>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>>> >>>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>>> sending a 428 and >>>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>>> verifier might send. >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>>>>>>> Sent: 22 September 2006 15:13 >>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>>>>>>>> When an Update is sent. Are there any conditions >>>>>> under which >>>>>>>>>>>>>>> it might >>>>>>>>>>>>>>> be rejected. Bad identity for example. I think that >>>>>>>>>>> might need a >>>>>>>>>>>>>>> little discussion and also what the UA does >> when it sends >>>>>>>>>>>>> an update >>>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>>> situation where it is >>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>>> purposes such as >>>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>>> because connected >>>>>>>>>>>>>> identity fails. >>>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>> I'm not sure about this. At the least I think this >>>> one needs >>>>>>>>>>>>> some clear >>>>>>>>>>>>> explanation of the SHOULD NOT - about the conditions when >>>>>>>>>>> it can be >>>>>>>>>>>>> violated. >>>>>>>>>>>>> >>>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>>> challenge on an >>>>>>>>>>>>> in-dialog request. In some cases it is the right >>>> thing to do. >>>>>>>>>>>>> A UA that imposes such a requirement will be >>>> limited in what >>>>>>>>>>>>> it can do, >>>>>>>>>>>>> but that may still be right in some cases. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>>> Identity header field >>>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported >> Certificate' or >>>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>> This requirement would force the authentication >> service to >>>>>>>>>>> be dialog >>>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>>> back into the >>>>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>>>> to tell the >>>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>>>> results in one of >>>>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>>>> for the purpose of >>>>>>>>>>>>>> connected identity. If solely for the purpose of >> connected >>>>>>>>>>>>> identity there is >>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>>>> any further >>>>>>>>>>>>>> action". >>>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>>> >>>>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>>>> purpose of the >>>>>>>>>>>>> verifier is ultimately to drive an authorization >>>> decision. If >>>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>>> identity, then the >>>>>>>>>>>>> request should be permitted to continue as if the >> identity >>>>>>>>>>>>> was not present. >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunately this would seem to require a >> revision to 4474 >>>>>>>>>>>>> even though >>>>>>>>>>>>> the paint is hardly dry on it. >>>>>>>>>>>>> >>>>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>>>> cause the >>>>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>>>> *not* done, >>>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>>> change to 4474. >>>>>>>>>>>>> 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 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 10 16:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOSj-0005TK-W0; Tue, 10 Oct 2006 16:44:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOSh-0005Sx-Su for sip@ietf.org; Tue, 10 Oct 2006 16:44:27 -0400 Received: from mx.plaxo.com ([66.151.128.13] helo=mx10.plaxo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOSg-0004rx-3t for sip@ietf.org; Tue, 10 Oct 2006 16:44:27 -0400 Received: from bes05.plaxo.com (bes05.plaxo.com [10.1.10.5]) by mx10.plaxo.com (Postfix) with QMQP id CFF6E47 for ; Tue, 10 Oct 2006 13:44:25 -0700 (PDT) Message-ID: <1160513065.24073.36393.sendUpdate@mx.plaxo.com> Date: 10 Oct 2006 20:44:25 -0000 From: "Eric Burger" To: "SIP List" Precedence: bulk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_-------==2277099171" X-Spam-Score: 0.9 (/) X-Scan-Signature: 1b82b4ba484bbe86cdae6d5f8b2d2ccb Subject: [Sip] Staying in touch X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Reply-To: Plaxo Contact Update for Eric Burger 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. --_-------==2277099171 Content-Type: multipart/alternative; boundary="_--=======972451383" --_--=======972451383 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear SIP, I'm updating my address book. Please take a moment to update me with your latest contact info. Click the following link to correct or confirm your information: https://www.plaxo.com/edit_contact_info?r=47246236909-7189876-568817039 Name: SIP List Job Title: Company: IETF Work E-mail: sip@ietf.org Work Phone: Work Fax: Work Address Line 1: Work Address Line 2: Work City, State, Zip: Mobile Phone: Home E-mail: Home Phone: Home Fax: Home Address Line 1: Home Address Line 2: Home City, State, Zip: Birthday: P.S. I've included my Plaxo card below so that you have my current information. I've also attached a copy as a vCard. +----------------- | Eric Burger | eburger@cantata.com | Chief Technology Officer | | Cantata Technology, Inc. | 18 Keewaydin Dr. | work: +1 603 890 7587 | fax: +1 603 457 5933 | web: http://www.cantata.com +------------------------------------- ____________________________________________________________ This message was sent to you by eburger@cantata.com via Plaxo. To opt out: https://www.plaxo.com/opt_out?r=47246236909-7189876-568817039 Plaxo's Privacy Policy: http://www.plaxo.com/support/privacy --_--=======972451383 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Your Contact Info
=20 =20 =20 =20

Dear SIP,

I'm updating= my address book. Please take a moment to update me with your latest cont= act info.

Thanks,
Eric Burger

 

 =20 =20 =20
=20 =20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20
=20
=20 =20 =20
=09 SIP List =20
no title
<= /td> =20 IETF=
=09 =09 United States= of America =09 =09
=20 sip@ietf.org
=20 =20 no web page
IM: none
 <= /td> =20 =20 <= td class=3D"table_small" nowrap align=3Dright>nonenone =20
tel: none
fax: none
mobile: 
pager: 
 
=20 =20 =20
=09 Personal Information =09
=09
=09 =09 no home address =09
=20 no email=
=20 =20 no web page
IM: none
 <= /td> =20 none =20 <= td class=3D"table_small" nowrap align=3Dright>none =20 =20
home: 
fax: none
mobile: 
birthday: none
=20
     
 
=20
Click to update your info 3D"->"3D"Click
=20
=20


P.S.= I've attached my current information in a vcard. If you=20 get Plaxo too, we can= stay connected without the hassle of sending emails back and forth.
<= /P> =20

If you do = not wish to receive update request emails from Eric Burger, click here= to opt-out.

--_--=======972451383-- --_-------==2277099171 Content-Type: text/x-vcard; charset=ISO-8859-1; name="Eric Burger.vcf" Content-Disposition: attachment; filename="Eric Burger.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD=20 VERSION:2.1 N:Burger;Eric;;; FN:Eric Burger ORG:Cantata Technology, Inc. TITLE:Chief Technology Officer ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;18 Keewaydin Dr.;Salem;NH;03031;US= A TEL;WORK;VOICE:+1 603 890 7587 TEL;WORK;FAX:+1 603 457 5933 EMAIL;PREF;INTERNET;WORK:eburger@cantata.com URL;WORK:http://www.cantata.com END:VCARD --_-------==2277099171 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 --_-------==2277099171-- From sip-bounces@ietf.org Tue Oct 10 17:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOwS-0005U0-24; Tue, 10 Oct 2006 17:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOwQ-0005Tv-DY for sip@ietf.org; Tue, 10 Oct 2006 17:15:10 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOwO-0008Jc-Ow for sip@ietf.org; Tue, 10 Oct 2006 17:15:10 -0400 Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9AKIIId011138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 10 Oct 2006 15:18:19 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <79B11B37-5038-4770-980B-7BA830808D75@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF SIP List From: Dean Willis Date: Tue, 10 Oct 2006 16:14:59 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Tracker for Agenda Topics for SIP at IETF 67 X-BeenThere: sip@ietf.org X-Mailman-Version: 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: http://www.softarmor.com/sipwg/meets/ietf67/requests.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 Tue Oct 10 17:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOxu-0005oz-Nz; Tue, 10 Oct 2006 17:16:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOxt-0005oB-N7 for sip@ietf.org; Tue, 10 Oct 2006 17:16:41 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOxr-0008U3-93 for sip@ietf.org; Tue, 10 Oct 2006 17:16: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 k9ALA0K13641; Tue, 10 Oct 2006 17:10:00 -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] RE: [Sip-implementors] Early media query Date: Tue, 10 Oct 2006 16:16:35 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110DFC9B3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [Sip-implementors] Early media query Thread-Index: AcbmIgVe3zH9Q/4ASqSIJlqTMxTcNAAfa9+QAYPBbFA= From: "Brian Stucker" To: "Darshan Bildikar" , "Retesh Chadha" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Short answer... It can be done, but it can get ugly and you can run into other problems. I recommend that you read the following draft: http://www.ietf.org/internet-drafts/draft-stucker-sipping-early-media-co ping-02.txt Regards, Brian > -----Original Message----- > From: Darshan Bildikar [mailto:dbildikar@ipunity.com]=20 > Sent: Monday, October 02, 2006 10:56 PM > To: 'Retesh Chadha'; Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip] RE: [Sip-implementors] Early media query >=20 > I don't think that even Method 3 and 4 are OK because they=20 > will involve a change in the origin line parameter of the SDP=20 > and that is not allowed as per the RFC.=20 >=20 > BTW, what was the rationale behind not allowing the origin=20 > line to change? > It makes implementing apps like prepaid and CRBT very=20 > difficult. Could someone please throw some light on this? >=20 > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf=20 > Of Retesh Chadha > Sent: Monday, October 02, 2006 5:46 PM > To: Udit_Goyal@3com.com > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Early media query >=20 > Hi Udit > Of all the methods you have specified, Method 1 and 2 are=20 > wrong as per the RFC which states that the sdp of all the=20 > provisional and 2xx response of INVITE should be same if they=20 > are present. >=20 > Both Method 3 and 4 look fine, with method 4 being better=20 > because in that case 200 ok for INVITE is only sent when the=20 > final negotiation (call media) is done. >=20 > Hope this helps. > -- > With Regards > Retesh Chadha >=20 >=20 > On 10/2/06, Udit_Goyal@3com.com wrote: > > Hi, > > > > I want to made an application where we can use early media=20 > for playing > > initial in-band announcements, and then finally connecting=20 > the caller to > > actual callee (eg prepaid card application). > > > > I want to know which is the correct way to support this as=20 > per SIP RFC. > > > > Method 1: > > > > > > Caller Callee > > | | > > | | > > |(1) INVITE with offer | > > |---------------------------->| > > | | > > | | > > |(2) 183 with answer 1 | > > |<----------------------------| > > | | > > | | > > |(3) 200 OK with SDP | > > |<----------------------------| > > | | > > | | > > |(4) ACK | > > |---------------------------->| > > | | > > > > > > (2) contains SDP of announcement server > > (3) contains SDP of callee > > > > > > Method 2: > > > > Caller Callee > > | | > > | | > > |(1) INVITE with offer | > > |---------------------------->| > > | | > > | | > > |(2) 183 with answer 1 | > > |<----------------------------| > > | | > > | | > > |(3) PRACK | > > |---------------------------->| > > | | > > | | > > |(4) 200 PRACK | > > |<----------------------------| > > | | > > | | > > |(5) 200 INVITE with sdp | > > |<----------------------------| > > | | > > | | > > |(6) ACK | > > |---------------------------->| > > | | > > | | > > | | > > | | > > > > (2) contains SDP of announcement server > > (5) contains SDP of callee > > > > > > Method 3: > > > > Caller Callee > > | | > > | | > > |(1) INVITE with offer | > > |---------------------------->| > > | | > > | | > > |(2) 183 with answer 1 | > > |<----------------------------| > > | | > > | | > > |(3) PRACK | > > |---------------------------->| > > | | > > | | > > |(4) 200 PRACK | > > |<----------------------------| > > |(5) 200 OK | > > |<----------------------------| > > | | > > |(6) ACK | > > |---------------------------->| > > | | > > |(7)Re-INVITE with SDP | > > |<----------------------------| > > | | > > | | > > |(8) 200 OK with SDP | > > |---------------------------->| > > | | > > |(9) ACK | > > |---------------------------->| > > > > (2) contains SDP of announcement server > > (5) contains no SDP > > (7) contains SDP of callee > > (8) contains answer of caller for callee offer > > > > Her, UDATE can also be used instead of Re-invites. > > > > Method 4: > > > > Caller Callee > > | | > > | | > > |(1) INVITE with offer | > > |---------------------------->| > > | | > > | | > > |(2) 183 with answer 1 | > > |<----------------------------| > > | | > > | | > > |(3) PRACK | > > |---------------------------->| > > | | > > | | > > |(4) 200 PRACK | > > |<----------------------------| > > |(5) UPDATE (callee offer) | > > |<----------------------------| > > | | > > |(6) 200 UPDATE (answer) | > > |---------------------------->| > > | | > > |(7) 200 INVITE | > > |---------------------------->| > > | | > > |(8) ACK | > > |---------------------------->| > > > > > > In this case, when callee answers, UPDATE is sent to caller=20 > to negoitate > > audio with caller, and then 200 OK is sent for the initial INVITE. > > > > Regards, > > Udit > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >=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 Tue Oct 10 21:14:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXSdv-0007cb-97; Tue, 10 Oct 2006 21:12:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXSds-0007cF-I2; Tue, 10 Oct 2006 21:12:16 -0400 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXSdr-000109-Bc; Tue, 10 Oct 2006 21:12:16 -0400 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 21:12:15 -0400 Received: from 10.128.41.19 ([10.128.41.19]) by ma02exchtmp01.Cantata.com ([10.128.18.41]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Oct 2006 01:12:13 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 10 Oct 2006 21:12:09 -0400 From: Eric Burger To: Sipping , SIP List Message-ID: Thread-Topic: [Sipping] Staying in touch Thread-Index: Acbs0kYZhHKDHljFEdun3QAWy5cvmw== In-Reply-To: <1160513065.24073.36394.sendUpdate@mx.plaxo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 01:12:15.0338 (UTC) FILETIME=[49E094A0:01C6ECD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Sip] Re: [Sipping] Staying in touch X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sometimes one does something stupid; other times one does something dumb. I think I managed to do stupid and dumb all at once. Sorry for the spam, but I hope there was SOME humor value... -- - Eric _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 00:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXW40-0000Pg-Bd; Wed, 11 Oct 2006 00:51:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXW3z-0000Pa-AC for sip@ietf.org; Wed, 11 Oct 2006 00:51:27 -0400 Received: from celtic-out.kyocera-wireless.com ([206.169.67.126] helo=celtic.intra.kyocera-wireless.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXW3w-0007J4-5h for sip@ietf.org; Wed, 11 Oct 2006 00:51:27 -0400 Received: from [172.20.94.158] (pptp158.intra.kyocera-wireless.com [172.20.94.158]) by celtic.intra.kyocera-wireless.com (8.12.8/8.12.3) with ESMTP id k9B4pM7U015913 for ; Tue, 10 Oct 2006 21:51:22 -0700 (PDT) Message-ID: <452C78E0.2050701@ktrc-na.com> Date: Tue, 10 Oct 2006 21:53:52 -0700 From: Tim Thome Organization: Kyocera Telecommunications Research Corp User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: SIP List Subject: Re: [Sip] Staying in touch References: <1160513065.24073.36393.sendUpdate@mx.plaxo.com> In-Reply-To: <1160513065.24073.36393.sendUpdate@mx.plaxo.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: c52a6b2685a9a1f963a24bd74e30b072 X-BeenThere: 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="===============0400820236==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0400820236== Content-Type: multipart/alternative; boundary="------------050306040407050705020900" This is a multi-part message in MIME format. --------------050306040407050705020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Taken care of... Tim (going back into lurk mode) ------------------------------------------------------------------------ /You will no longer receive e-mails from Plaxo to your e-mail address: *sip@ietf.org*. If you continue to receive e-mails from Plaxo, please contact Plaxo Customer Care at support@plaxo.com ./ // /We're sorry you've decided to opt-out permanently from receiving Update Requests sent by Plaxo members. We hope you'll check back with us in the future as we continue to grow and improve our service./ /If you ever wish to receive Update Requests from Plaxo members again and would like to reverse this opt-out, please e-mail us at un-opt-out@plaxo.com . Thank you./ /Return to Plaxo Homepage / ------------------------------------------------------------------------ Eric Burger wrote: > > Dear SIP, > > I'm updating my address book. Please take a moment to update me with > your latest contact info. > > Thanks, > Eric Burger > > > > > SIP List > no title > > IETF > United States of America > > sip@ietf.org > no web page > IM: none > > > tel: none > fax: none > mobile: none > pager: none > > > > *Personal Information* > no home address > > no email > no web page > IM: none > > > home: none > fax: none > mobile: none > birthday: none > > > > > > > > > > Click to update your info > > ->Click here to correct or confirm your info > > > > > > P.S. I've attached my current information in a vcard. If you get Plaxo > too, we can stay connected without > the hassle of sending emails back and forth. > > If you do not wish to receive update request emails from Eric Burger, > click here > to > opt-out. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------------------------------------------------------------------------ -- Tim Thome Systems Design Engineer, Senior Staff Kyocera Telecommunications Research Corp. San Diego, CA --------------050306040407050705020900 Content-Type: multipart/related; boundary="------------020208030109090303050409" --------------020208030109090303050409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Taken care of...

Tim

(going back into lurk mode)



You will no longer receive e-mails from Plaxo to your e-mail address: sip@ietf.org.

If you continue to receive e-mails from Plaxo, please contact Plaxo Customer Care at support@plaxo.com.

We're sorry you've decided to opt-out permanently from receiving Update Requests sent by Plaxo members. We hope you'll check back with us in the future as we continue to grow and improve our service.

If you ever wish to receive Update Requests from Plaxo members again and would like to reverse this opt-out, please e-mail us at un-opt-out@plaxo.com. Thank you.

Return to Plaxo Homepage





Eric Burger wrote:
Your Contact Info

Dear SIP,

I'm updating my address book. Please take a moment to update me with your latest contact info.

Thanks,
Eric Burger

 
SIP List
no title
IETF
 United States of America

sip@ietf.org
no web page
IM: none
tel:  none
fax:  none
mobile:  none
pager:  none
 
Personal Information
no home address

no email
no web page
IM: none
home:  none
fax:  none
mobile:  none
birthday:  none



     
 
Click to update your info ->Click here to correct or confirm your info


P.S. I've attached my current information in a vcard. If you get Plaxo too, we can stay connected without the hassle of sending emails back and forth.

If you do not wish to receive update request emails from Eric Burger, click here to opt-out.

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


-- 
Tim Thome
Systems Design Engineer, Senior Staff
Kyocera Telecommunications Research Corp.
San Diego, CA
--------------020208030109090303050409 Content-Type: image/gif; name="permanent_opt_out_completed.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="permanent_opt_out_completed.gif" R0lGODlhCAItAMQAAEBAQL+/v4CAgO/v7xAQEDAwMM/Pz9/f32BgYCAgIJ+fn6+vr3BwcFBQ UI+PjwAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAAIAi0AAAX/ICSOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWG h4hpBgGMVouNiTWLCwKVAg4BkUYGDpUKB4cGCpYBoF0AD6lWqKqaM6mwsQQIA64/AgmxqQUK ggcIBLq7p7CrxbYxwroEBsgrpiwGBcqwCDvQUdgrDNSpDcStNAO1PawPzjCwCYwBDrmpCegm CwgJAC0HwamzldOw9zbo2YsiEOCKAeYeEGhQiQEqB+DOyTjgAFWmcsfksfhHYoC/Bws0juDI 4mMDciIW/+h7IMAGyScvVSCARUAAShHjIs4QAOsiD3MiN6YyKMIALAZBIcRE4QBWgRMLYmlL NzTKUqg0m5UBKoNnKp87uCZFcXVpAAEAADAIWWKUAFAHHPY6KyDTAAcN1EKjmJbBVAgHRuUV wJbEAUsiAjhs4OBmRwcIADDWdrhS4sWNSVRSZ+kvhHcPtJpoAKulCLd2FURuoODmZnidXRhA m1aA6BGV65aw1AvC6wcJYp/4CFE2bQC2TVTurRoAAp8DFOR9XiJ3UdoMbosQS0KBQ+S3z5pD 4KmEeLWFTcyunYn72BJlq4o4kHDXbVYOVKZq6ZXwylS9KPDfA73hVB884cEyAP9psmgHgQMD skRCAAoymNVI1IA1glHDoBBVhxCw4p8uCYjWjYYnIKQMLROWBp98J57AIXAuqCgMiyNQ+AAA 0uhijQGgpWJNjhUKgxQJ7gUQpDfkeCWMQfQJU4CD3Pjo3nsY7ljChxICthIAHxEADSsMrMSf NxES0JQwYpLwjj2gEYCSjg9YKMtNVQIHwEpHQkCnnTSRE6MJTppGVkasNBChQloNmkI+3RQw p4skkOQoCWs+0KcKkFIjKZEPFPBRLBAqUxidM62IZEYQcEkAAKA95Rs1AHW6Y5jYHCgMlifE dABoWrFSgCkG6DNkiPvsAkAvTtYZwAKjPvActJSK4ED/ayMoUC2dCtUlICzF+QnuCKk+YAq3 NQXwbSrFMeIUO46JUC6Kq6YSbCwNgGKAOQC5uwu8K3xkE2AWHkunoSKQ5G+oAJuQJ70mCFzL AQWDussCAQAKAMYWGoRuL3et5JNYAxhLjrYAAhZAuZgEcG+oxBqbLU1srRsOr1mu82yZCu9z E8oPkGMOAWA5+Q1OZo5QsnwpsOJxLKLRaZCIJbxzJLdRx3RVCeZAvF1PX3tTwkcmMr0C0JtC 8NG51SZs9tb1PuD1zKmkvXZi6qDEb9wWh0YCl0cjG45XREGQqqyzftWiQj8rKMI7zCx+M85K dbMjOakem+VF5oQrgpPYlHtT/7kpqotWRqhWvc98sGhDON5Cqq5QpWaf0LUKtwtublvVvjQA O8CbUq42QLfbduVaZlm4CbnL1Drv7MJOYHewpAf0RanLLpHuI7xToPQjOAlW5iaAPaPmInxE Oe3KJPD9m2nFb45p5jjm5G6sJr59YoCifjxXQJNfWkAjPYRxT3krKFd6Iua4A3YEFoF7Cbco 5Q/EKa0aBXxR8ty2QRQosCQgumDsxKU4i4GFTtg7HgTy9DKJHMApAvzIRcTnJngIcH4QANoC Hbg+p1hiAVOxHKWudD/N5K+I8rKcxQzIlWZ1I4N8Q6AKCqUCmozgSsgziASVYZqt9Ww/GiQK 3MJ3FP+hdFCKKJTcCcFGwi4ZsYRcmWCGPsdGDlruTCWM4vqyuAJ13DB+vSHiEQcZjjxtrBZI PBjXjuGkP8YPildk1RiLoo4UAC1wWHyJ74DHDlN4UT6KZJ8Ya2cCOsWjj6TkYxvXmMdVQpKM cDwGnQrgSB7RsZV+dCSz6hjJyeFskmqrGwsEOTkk3nJ7+iBKIv93DC7FyzzMvBkwP1M9FJij QFeakaGmGTYCqIdSoZQiB5dnAtAYkHmrK4E2pcdKuanxlSKwUC8lMoBqroCGI/BH2kqpQvXt UZUpSJWcVkDM/ekPf60I5wr9B8YovrChKVAoD6fppIGWIFOnDBtISvAwcW7/w54j6ChgnCK5 UZ7xBJmaXgrytECRptGE72yjBSFQT6aJ5R3kRKg7yeUzFdSURiSYkUF/mUrJfaoEesvfQd9o 0CLOKHDFYqgbNTrP7+FkiYu8GbBACA/o5GmnGm1TSirZPVg46AQPBQ5KZmRB0PTmVzHZasBi gQDtlGKk8FgrSdkZU762UVNKu+Y8YSktEzRObBY7akfmiaMDjOqfAA0oviyxp5Ep1ZhLJWxZ hSQAnkmViRmJKjwYUAkE0BKrejQcTcDEqf/Yoz5WTQg/7JSecr1qpifIEwFIWy6/hTQWtExW B23L2hR45ElgaqhueQs1mDrXrxMsQGdjpcfj7oM8/51FhWGAC4Di9JYhlajshnSRFngolVfT HEBvdWGogur0vWO90Wezur8ALCocEuWOUH1ZHV3tY4fmiFb0grorFqyXZkhdUqheN15dHOSr T+KpMgiQnpf6FbpOUcawUuvYSwHKNOrtBsKABlwuQZabrQLUQgrjXqbCNyWgScACfqqV/Obv MEsqAAPIYePJLSBILVBAfYLzzPoB4x/0+nEsXJAxWSDgLzbqVuIKp+TzKocBAu7uhOw0C21Y 2JXOPRi19jGw1NJUAdFKQF070luELUDFDVhgABKyYzpBVhKMeGYRFnFWHPzOZdcANAwaZk3U BUDPuBH0C/7c545AggUHUGr0Cx7hU0Y0GgehjPSlV8AOTh8aBY9AtMrmdudSDwGLppbcOVPN 6kKgutUSbbWsBfFqVsd61rjuQ61Tfetc+xoPuzZ1r39N7GIb+9jITrayl83sZjv72dCOtrSn Te1qW/va2M62tredhRAAADs= --------------020208030109090303050409-- --------------050306040407050705020900-- --===============0400820236== 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 --===============0400820236==-- From sip-bounces@ietf.org Wed Oct 11 10:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfD9-0004Kl-70; Wed, 11 Oct 2006 10:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfD7-0004JH-Ew for sip@ietf.org; Wed, 11 Oct 2006 10:37:29 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXfD6-0000XA-DG for sip@ietf.org; Wed, 11 Oct 2006 10:37:29 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2006 07:37:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AY8CAL+dLEU X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="1857519529:sNHT41293232" 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 k9BEbQuB017072; Wed, 11 Oct 2006 07:37:26 -0700 Received: from [192.168.1.3] (sjc-vpn5-444.cisco.com [10.21.89.188]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9BEbObI028575; Wed, 11 Oct 2006 07:37:25 -0700 (PDT) In-Reply-To: <452B9E1C.4030804@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> <452B9E1C.4030804@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) Date: Tue, 10 Oct 2006 13:47:55 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=23692; t=1160577446; x=1161441446; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=20p-connecte=20d-id=20entity-01=20comments); X=v=3Dcisco.com=3B=20h=3D3fqUHHJC0+IiSnYuEGg8Vl61qH0=3D; b=Po8E0D0f1UlvfGbpROpkpsHNmiOQHwYT3EIpUsT9WUwCOORKLnvhZC3jqIqpnFg+8fnbBdz8 JpIlvQoBJsZ7nCnB0Z3ZUJTNqVBqNz4jz2yVWbmUbkllyRS7UmqPNn5v; 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: 07d4bcb4600b627a0786c2557bc62e06 Cc: SIP , "Elwell, John" , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 generally on board with things like you are suggesting below and what is suggested in draft-rosenberg-sip-identity-coexistence. However, I want to think very carefully about the security properties of not rejecting things that failed based on security properties - I'm not sure what I think of this yet. Any time you allow a security action that failed to continue sending the request downstream, you run the risk that something further down stream assumes that the security action worked because it must have happened upstream. Clearly from a security point of view it would be better not to have upstream elements do the security validation for a downstream element but we did decide long ago that when doing Identity we were going to allow for this so that we could migrate from UAs that do not support Identity to system that does. So let me flip this around the other way and ask - do we really need to allow for a request that failed verification to not result in an error? Are there use cases where the verification would fail and we really do want to continue with the message? If these cases would only happen in a fairly broken system, then it might not be worth the security problems they would cause. I don't know what I think but I am interested in where we might need this and if there might be other ways to skin the cat in those situations. Cullen On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > John, > > What you outline below is exactly what I had in mind. > > Paul > > Elwell, John wrote: >> Paul, >> Dan Wing made a suggestion that P-Asserted-Identity would fulfil your >> requirement. I guess it would work like this. >> A Verifier not located at the UAS would attempt to verify the >> signature in >> the Identity header field. >> - Case A - verification succeeds. The Verifier inserts into the >> forwarded >> request a P-Asserted-Identity header field containing the verified >> URI (from >> the From header field) in the forwarded request. The Identity and >> Identity-Info header fields will still be present and available >> should >> another verifier be encountered downstream. >> - Case B - verification fails but request not rejected. The >> verifier is >> unable to verify (e.g., because it can't dereference the URL) but >> according >> to policy does not reject the request. It simply forwards the >> request as is. >> If there is a further verifier downstream, that too can attempt to >> verify >> the signature. >> - Case C - verification fails but request is rejected. The >> verifier is >> unable to verify (e.g., bad signature) and according to policy it >> rejects >> the request. >> A UAS that does not contain a verifier can simply use P-Asserted- >> Identity, >> if present. >> This seems to have some synergy with >> draft-rosenberg-sip-identity-coexistence. In fact the relaxation >> of rules >> concerning rejection by a verifier that is unable to verify a >> signature >> might be beneficial to that proposal. >> I will omit discussion of the mechanics of documentation until I >> see what >> reaction there is to the technical proposal. >> John >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October >>> 2006 13:54 >>> To: Elwell, John >>> Cc: Cullen Jennings; Jon Peterson; SIP >>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>> draft-ietf-si p-connecte d-id entity-01 comments) >>> >>> >>> >>> Elwell, John wrote: >>>> Paul, >>>> >>>> Your message arrived just after I had submitted 02, so your >>> comments are not >>>> taken into account in that version. However, I felt it was >>> useful to get 02 >>>> out as a baseline for further discussion. >>> Sure. I too am interested in seeing other inputs on this subject. >>> >>>> It seems the remaining issue is whether to add an explicit >>> indication of >>>> removal of the Identity header field by a verifier that has >>> been unable to >>>> verify the signature. Whilst this may make sense, I am >>> concerned it starts >>>> to go beyond the scope of connected-identity, so I would like other >>>> opinions, especially from the chairs and from the authors >>> of Identity. >>> >>> Rather than adding something to indicate that identity has been >>> *removed* due to failure to verify, I am advocating adding >>> something to indicate that verification has *succeeded*, while >>> leaving the identity header in place. In this way, a downstream >>> element may *either* trust the info added by the verifier or do >>> its own verification of the identity header. >>> >>> Of course this is only significant if the verifier is doing work >>> for downstream elements, and not for itself. >>> >>> Paul >>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 05 October >>>>> 2006 16:29 >>>>> To: Elwell, John >>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>> >>>>> >>>>> >>>>> Elwell, John wrote: >>>>>> Paul, >>>>>> >>>>>> So your proposal is that the connected-identity RFC should >>>>> update RFC 4474 >>>>>> to somehow relax rules at a verifier. Correct? >>>>> Yeah, I think so. >>>>> >>>>>> So the next question concerns the way in which these >>> rules should be >>>>>> relaxed. One problem with the verifier not being located at >>>>> the UAS but at >>>>>> some proxy is that the UAS might be configured always to >>>>> trust identities >>>>>> received in requests via the verifier's proxy if an >>>>> Identity header field is >>>>>> present, on the assumption that the signature has been >>>>> checked by the >>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>> not reject a >>>>>> request with a bad signature, should remove the Identity >>>>> header field (and >>>>>> also Identity-Info) before forwarding the request towards >>>>> the target. >>>>> >>>>> (I think I have seen someone propose combining the use of >>>>> Identity and P-Asserted-Identity, though I don't recall the >>>>> details, or which draft it was. So what I am about to say might >>>>> bear no >>> relationship to that.) >>>>> I could see how Identity might be used between trust >>> domains, while >>>>> P-Asserted-Identity is used within a trust domain. In that >>>>> case, a verifier might run at the entry point to a trust domain >>>>> and if verification succeeds, insert a P-Asserted-Identity >>>>> header with a corresponding identity. It then might, or might >>>>> not, remove the Identity header. Recipients within the trust >>>>> domain could then use P-Asserted-Identity as the source of >>>>> identity info. (In this scenario, an identity header would only >>>>> be added to requests when they leave the trust domain.) >>>>> >>>>> In this kind of environment, it is only necessary for the >>> verifier to >>>>> omit the P-Asserted-Identity header when verification fails. >>>>> >>>>>> Under what conditions should a verifier remove an Identity >>>>> header field >>>>>> rather than rejecting with 436/437/438? My inclination >>>>> would be to leave it >>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>> concerned, and >>>>>> then make more precise statements concerning mid-dialog requests. >>>>>> Alternatively the update to RFC 4474 could just relax the >>> rules for >>>>>> mid-dialog requests. I think there is some merit in >>>>> relaxing the rules in >>>>>> general, because otherwise there might be situations where >>>>> a legitimate >>>>>> caller cannot establish a call because an Authentication >>>>> Service (outside >>>>>> the UAC's control) is inserting an unverifiable signature >>> (e.g., in >>>>>> Identity-Info placing a URL that the Verifier cannot >>>>> dereference for some >>>>>> reason). >>>>> What you say sounds reasonable to me. >>>>> >>>>> There is however some risk to having a verifier remove >>> identity. The >>>>> problem would be when there are potentially multiple >>> verifiers that >>>>> don't trust one another. If an early one removes the >>> header, then it >>>>> prevents a subsequent verifier from doing its own verification. >>>>> >>>>> This could come up if a request transits a domain on the way to >>>>> another domain. Each domain may wish to do its own verification. >>>>> >>>>> That is an advantage to having the verifier add something to >>>>> the request to indicate the result of its verification. >>>>> >>>>>> One consequence of the Verifier being separated from the >>>>> UAS is that we >>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>> its proxy (for >>>>>> similar reasons that you cited for the Authentication >>>>> Service earlier). So >>>>>> for mid-dialog requests we would need to mandate, or at >>>>> least recommend, >>>>>> that 436/437/438 should not be sent. >>>>> Right. >>>>> >>>>> Paul >>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 >>>>>>> October 2006 01:44 >>>>>>> To: Elwell, John >>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Elwell, John wrote: >>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>> >>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>> 436, 437 or 438, >>>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>> not by some >>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>>>>> in a proxy before the UAS? This rule would forbid that, >>>>>>> because it would cause that proxy to be call stateful. >>>>>>> >>>>>>> I think it would just be better to update the RFC, even >>>>>>> though that is a bit more trouble than not to. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>>> on the same >>>>>>>> dialog unless the From header field URI has changed, and in >>>>>>> such cases >>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>> Then a UAC, on >>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>> This would allow >>>>>>>> business as usual on this dialog (but without the benefit >>>>>>> of connected >>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>> any change to RFC >>>>>>>> 4474, because verification is optional anyway. >>>>>>>> >>>>>>>> Would this work? >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 >>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>> Subject: FW: Rejecting connected identity (was RE: draft- >>>>>>>>> ietf-sip-connected-id entity-01 comments) >>>>>>>>> >>>>>>>>> Cullen, Jon, >>>>>>>>> >>>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>>> you), I would greatly appreciate an opinion from each of >>>>>>>>> you on this remaining issue in connected-identity. Just to >>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to >>>>>>>>> return a 428 response if Identity is missing, but mandates >>>>>>>>> the sending of a 436, 437 or 438 response for certain >>>>>>>>> errors arising while verifying the signature. It seems that >>>>>>>>> for mid dialog requests this behaviour could be harmful. >>>>>>>>> What does the UAC for the mid dialog request do if it >>>>>>>>> receives 436, 437 or 438? If the mid-dialog request was >>>>>>>>> solely for the purpose of connected identity, it can give >>>>>>>>> up and allow the call to continue as is. But if the request >>>>>>>>> was for some other purpose (e.g., renegotiating the session >>>>>>>>> because of hold, say, or session timer refresh), the UAC >>>>>>>>> really wants it to work. For the normal case where the >>>>>>>>> Authentication Service is at a proxy, not at the UAC, the >>>>>>>>> UAC cannot force the Authentication Service to refrain from >>>>>>>>> putting this unverifiable signature in the mid-dialog >>>>>>>>> request, so any attempts to repeat the request would most >>>>>>>>> likely be doomed to getting the same response. >>>>>>>>> >>>>>>>>> It seems there are three things we could do, none very >>>>> attractive: >>>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>>> 4474 for a verifier by softening the requirements for >>>>>>>>> sending 436, 437 and 438 in response to mid-dialog >>>>>>>>> requests. But then a mid-dialog request from a rogue source >>>>>>>>> would be accepted. >>>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>>>>> at the AS. >>>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>>> way and therefore things like session refresh and session >>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>>> INVITE request, where there is nothing the UAC can do if >>>>>>>>> the AS inserts an Identity header that gets rejected with 436, >>>>>>> 437 or 438. >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>> September 2006 19:26 >>>>>>>>>> To: Elwell, John >>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: draft- >>>>>>>>>> ietf-sip-connected-id entity-01 comments) >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> I want to hear what others, especially Jon and Cullen, >>>>>>>>>> have to say about this. >>>>>>>>>> >>>>>>>>>> It is of some concern to me that a call might fail >>>>>>> because of some >>>>>>>>>> problem with the identity mechanism when the same call >>>>> might have >>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>> >>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>> implementation of the verifier. What to do in the case of >>>>>>>>>> the conditions that >>>>>>>>> lead to these >>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>> generate the >>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>> message. And the >>>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>>> message, such as whether it is in-dialog or not. >>>>>>>>>> >>>>>>>>>> Does it require a change to 4474 to permit that kind >>> of policy? >>>>>>>>>> It would be annoying if the end user had no control over >>>>>>>>>> the insertion and verification of identity, and it >>>>>>>>>> resulted in calls failing that the user would like to >>>>>>>>>> permit. But I suppose that is itself >>>>> a policy >>>>>>>>>> decision. There are certainly enterprises that want to >>>>>>>>>> exert that kind of control over what users are permitted >>>>>>>>>> to do. >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> Elwell, John wrote: >>>>>>>>>>> Paul, >>>>>>>>>>> >>>>>>>>>>> I agree with most of your points, and on reflection I think >>>>>>>>>> I agree that the >>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>> >>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>>> 'Use Identity >>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>> policy, so we could >>>>>>>>>>> say in connected-identity that policy should be to not >>>>> send 428. >>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>> because RFC 4474 says >>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>> Interestingly, though, >>>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>>> procedures of >>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>>> given on how to >>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>> authoritative for the >>>>>>>>>>> domain. >>>>>>>>>>> >>>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>>> connected-identity >>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>>> of mid-dialog >>>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>>> 4474 as well as >>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>>> to remove some of >>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>> >>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>> responses will be sent, >>>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>>> inability to >>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>>> UPDATE or >>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>> session timer refresh >>>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>>> call will fail (in >>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>> the session >>>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>>> to caller ID >>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>> impossible to establish a >>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>> ability to rectify the >>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>> Authentication Service >>>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>>> In the connected >>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>> already established >>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>> >>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>> wrong source, then >>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>>> thing to do, and >>>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>>> indeed be the wrong >>>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>>> response codes can >>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>> >>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>> sending a 428 and >>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>> verifier might send. >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>> September 2006 15:13 >>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] When >>>>>>>>>>>>>> an Update is sent. Are there any conditions >>>>> under which >>>>>>>>>>>>>> it might be rejected. Bad identity for example. I >>>>>>>>>>>>>> think that >>>>>>>>>> might need a >>>>>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>>>>> an update >>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>> situation where it is >>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>> purposes such as >>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>> because connected >>>>>>>>>>>>> identity fails. >>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>> I'm not sure about this. At the least I think this >>> one needs >>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the >>>>>>>>>>>> conditions when >>>>>>>>>> it can be >>>>>>>>>>>> violated. >>>>>>>>>>>> >>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>> challenge on an >>>>>>>>>>>> in-dialog request. In some cases it is the right >>> thing to do. >>>>>>>>>>>> A UA that imposes such a requirement will be >>> limited in what >>>>>>>>>>>> it can do, but that may still be right in some cases. >>>>>>>>>>>> >>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>> Identity header field >>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>> This requirement would force the authentication service to >>>>>>>>>> be dialog >>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>> back into the >>>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>>> to tell the >>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>> >>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>>> results in one of >>>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>>> for the purpose of >>>>>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>>>>> identity there is >>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>>> any further >>>>>>>>>>>>> action". >>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>> >>>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>>> purpose of the verifier is ultimately to drive an >>>>>>>>>>>> authorization >>> decision. If >>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>> identity, then the >>>>>>>>>>>> request should be permitted to continue as if the >>>>>>>>>>>> identity was not present. >>>>>>>>>>>> >>>>>>>>>>>> Unfortunately this would seem to require a revision to >>>>>>>>>>>> 4474 even though the paint is hardly dry on it. >>>>>>>>>>>> >>>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>>> cause the >>>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>>> *not* done, >>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>> change to 4474. >>>>>>>>>>>> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 11:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXg0y-0004At-KL; Wed, 11 Oct 2006 11:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXg0w-00045X-My for sip@ietf.org; Wed, 11 Oct 2006 11:28:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXg0v-0006wi-Jn for sip@ietf.org; Wed, 11 Oct 2006 11:28:58 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Oct 2006 08:28:57 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9BFSvkm028137; Wed, 11 Oct 2006 08:28:57 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9BFStin007235; Wed, 11 Oct 2006 08:28:55 -0700 (PDT) From: "Dan Wing" To: "'Cullen Jennings'" , "'Paul Kyzivat'" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) Date: Wed, 11 Oct 2006 08:28:54 -0700 Keywords: direct-to-dwing Message-ID: <154201c6ed49$f72a7c30$c5f0200a@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: AcbtQsZ3pKZNMAuLQzeXV8qG9wRVQQABbwMQ In-Reply-To: <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> DKIM-Signature: a=rsa-sha1; q=dns; l=26362; t=1160580537; x=1161444537; c=relaxed/simple; s=sjdkim1002; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=20p-connecte=20d-id=20entity-01=20comments); X=v=3Dcisco.com=3B=20h=3DB+c744CGNym/MRqMUakEMvWTfQY=3D; b=Bc5K/U9npWupRBu3CPzm8DsGyugjUmLb6MoCJKGKLtTEzIfdZwrOxNvlHUnI492Loa4aGhXO uReKIHMSMLdysABlm56AfBHyrg5BHee2xAKfNjNsHfYCjClbU0vB94uC; Authentication-Results: sj-dkim-1.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 94375f06b91351a23b2e62bbf6b5a18c Cc: 'SIP' , "'Elwell, John'" , 'Jon Peterson' X-BeenThere: sip@ietf.org X-Mailman-Version: 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 generally on board with things like you are suggesting below and > what is suggested in draft-rosenberg-sip-identity-coexistence. > However, I want to think very carefully about the security > properties > of not rejecting things that failed based on security properties - > I'm not sure what I think of this yet. Well, let's look at email with S/MIME signatures and PGP signatures. To my experience, mail user agents display an indication that the signature failed, or make you click some special "I don't care" button to see a message with a failed signature. But you're still able to see the message. Trying to improve upon that is an admirable goal. However, it gets especially complicated with VoIP because it doesn't have the store-and-forward properties of email (where you could, in theory, delay message delivery while you're validating a signature -- so that, for example, a DNS outage would cause a delivery delay but wouldn't cause a failure-to-authenticate and therefor a non-delivery). > Any time you allow a security action that failed to continue sending > the request downstream, you run the risk that something further down > stream assumes that the security action worked because it must have > happened upstream. If P-A-I indicates "I validated the signature", there is no assumption at all -- the presence of that header indicates the signature was validated. If this is a critical service (your voicemail box, as one possible example), it might ignore the P-A-I and re-validate the signature. > Clearly from a security point of view it would be > better not to have upstream elements do the security > validation for a > downstream element but we did decide long ago that when doing > Identity we were going to allow for this so that we could migrate > from UAs that do not support Identity to system that does. Similar arguments are made all the time in deployments of antivirus and spam checkers in email -- they have soft positives (where they suspect something is amiss -- an encrypted ZIP file, for example) and hard positives (where a virus signature positively matches). I'm not sure it's the IETF's place to specify how this should be deployed, but rather to provide the tools so software can interoperate with whatever deployment model someone desires. -d > So let me flip this around the other way and ask - do we really need > to allow for a request that failed verification to not result in an > error? Are there use cases where the verification would fail and we > really do want to continue with the message? If these cases would > only happen in a fairly broken system, then it might not be > worth the > security problems they would cause. I don't know what I think but I > am interested in where we might need this and if there might > be other ways to skin the cat in those situations. > > Cullen > > > On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > > > John, > > > > What you outline below is exactly what I had in mind. > > > > Paul > > > > Elwell, John wrote: > >> Paul, > >> Dan Wing made a suggestion that P-Asserted-Identity would > fulfil your > >> requirement. I guess it would work like this. > >> A Verifier not located at the UAS would attempt to verify the > >> signature in > >> the Identity header field. > >> - Case A - verification succeeds. The Verifier inserts into the > >> forwarded > >> request a P-Asserted-Identity header field containing the > verified > >> URI (from > >> the From header field) in the forwarded request. The Identity and > >> Identity-Info header fields will still be present and available > >> should > >> another verifier be encountered downstream. > >> - Case B - verification fails but request not rejected. The > >> verifier is > >> unable to verify (e.g., because it can't dereference the URL) but > >> according > >> to policy does not reject the request. It simply forwards the > >> request as is. > >> If there is a further verifier downstream, that too can > attempt to > >> verify > >> the signature. > >> - Case C - verification fails but request is rejected. The > >> verifier is > >> unable to verify (e.g., bad signature) and according to policy it > >> rejects > >> the request. > >> A UAS that does not contain a verifier can simply use P-Asserted- > >> Identity, > >> if present. > >> This seems to have some synergy with > >> draft-rosenberg-sip-identity-coexistence. In fact the relaxation > >> of rules > >> concerning rejection by a verifier that is unable to verify a > >> signature > >> might be beneficial to that proposal. > >> I will omit discussion of the mechanics of documentation until I > >> see what > >> reaction there is to the technical proposal. > >> John > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October > >>> 2006 13:54 > >>> To: Elwell, John > >>> Cc: Cullen Jennings; Jon Peterson; SIP > >>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>> draft-ietf-si p-connecte d-id entity-01 comments) > >>> > >>> > >>> > >>> Elwell, John wrote: > >>>> Paul, > >>>> > >>>> Your message arrived just after I had submitted 02, so your > >>> comments are not > >>>> taken into account in that version. However, I felt it was > >>> useful to get 02 > >>>> out as a baseline for further discussion. > >>> Sure. I too am interested in seeing other inputs on this subject. > >>> > >>>> It seems the remaining issue is whether to add an explicit > >>> indication of > >>>> removal of the Identity header field by a verifier that has > >>> been unable to > >>>> verify the signature. Whilst this may make sense, I am > >>> concerned it starts > >>>> to go beyond the scope of connected-identity, so I would > like other > >>>> opinions, especially from the chairs and from the authors > >>> of Identity. > >>> > >>> Rather than adding something to indicate that identity has been > >>> *removed* due to failure to verify, I am advocating adding > >>> something to indicate that verification has *succeeded*, while > >>> leaving the identity header in place. In this way, a downstream > >>> element may *either* trust the info added by the verifier or do > >>> its own verification of the identity header. > >>> > >>> Of course this is only significant if the verifier is doing work > >>> for downstream elements, and not for itself. > >>> > >>> Paul > >>> > >>>> John > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 05 > October > >>>>> 2006 16:29 > >>>>> To: Elwell, John > >>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>> > >>>>> > >>>>> > >>>>> Elwell, John wrote: > >>>>>> Paul, > >>>>>> > >>>>>> So your proposal is that the connected-identity RFC should > >>>>> update RFC 4474 > >>>>>> to somehow relax rules at a verifier. Correct? > >>>>> Yeah, I think so. > >>>>> > >>>>>> So the next question concerns the way in which these > >>> rules should be > >>>>>> relaxed. One problem with the verifier not being located at > >>>>> the UAS but at > >>>>>> some proxy is that the UAS might be configured always to > >>>>> trust identities > >>>>>> received in requests via the verifier's proxy if an > >>>>> Identity header field is > >>>>>> present, on the assumption that the signature has been > >>>>> checked by the > >>>>>> verifier. Therefore it sounds like the verifier, if it does > >>>>> not reject a > >>>>>> request with a bad signature, should remove the Identity > >>>>> header field (and > >>>>>> also Identity-Info) before forwarding the request towards > >>>>> the target. > >>>>> > >>>>> (I think I have seen someone propose combining the use of > >>>>> Identity and P-Asserted-Identity, though I don't recall the > >>>>> details, or which draft it was. So what I am about to > say might > >>>>> bear no > >>> relationship to that.) > >>>>> I could see how Identity might be used between trust > >>> domains, while > >>>>> P-Asserted-Identity is used within a trust domain. In that > >>>>> case, a verifier might run at the entry point to a > trust domain > >>>>> and if verification succeeds, insert a P-Asserted-Identity > >>>>> header with a corresponding identity. It then might, or might > >>>>> not, remove the Identity header. Recipients within the trust > >>>>> domain could then use P-Asserted-Identity as the source of > >>>>> identity info. (In this scenario, an identity header > would only > >>>>> be added to requests when they leave the trust domain.) > >>>>> > >>>>> In this kind of environment, it is only necessary for the > >>> verifier to > >>>>> omit the P-Asserted-Identity header when verification fails. > >>>>> > >>>>>> Under what conditions should a verifier remove an Identity > >>>>> header field > >>>>>> rather than rejecting with 436/437/438? My inclination > >>>>> would be to leave it > >>>>>> as a matter of policy as far as the update to RFC 4474 is > >>>>> concerned, and > >>>>>> then make more precise statements concerning > mid-dialog requests. > >>>>>> Alternatively the update to RFC 4474 could just relax the > >>> rules for > >>>>>> mid-dialog requests. I think there is some merit in > >>>>> relaxing the rules in > >>>>>> general, because otherwise there might be situations where > >>>>> a legitimate > >>>>>> caller cannot establish a call because an Authentication > >>>>> Service (outside > >>>>>> the UAC's control) is inserting an unverifiable signature > >>> (e.g., in > >>>>>> Identity-Info placing a URL that the Verifier cannot > >>>>> dereference for some > >>>>>> reason). > >>>>> What you say sounds reasonable to me. > >>>>> > >>>>> There is however some risk to having a verifier remove > >>> identity. The > >>>>> problem would be when there are potentially multiple > >>> verifiers that > >>>>> don't trust one another. If an early one removes the > >>> header, then it > >>>>> prevents a subsequent verifier from doing its own verification. > >>>>> > >>>>> This could come up if a request transits a domain on > the way to > >>>>> another domain. Each domain may wish to do its own verification. > >>>>> > >>>>> That is an advantage to having the verifier add something to > >>>>> the request to indicate the result of its verification. > >>>>> > >>>>>> One consequence of the Verifier being separated from the > >>>>> UAS is that we > >>>>>> don't want to rely on stateful behaviour at the Verifier or > >>>>> its proxy (for > >>>>>> similar reasons that you cited for the Authentication > >>>>> Service earlier). So > >>>>>> for mid-dialog requests we would need to mandate, or at > >>>>> least recommend, > >>>>>> that 436/437/438 should not be sent. > >>>>> Right. > >>>>> > >>>>> Paul > >>>>> > >>>>>> John > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 > >>>>>>> October 2006 01:44 > >>>>>>> To: Elwell, John > >>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Elwell, John wrote: > >>>>>>>> Thinking further on this, perhaps there is a 4th way: > >>>>>>>> > >>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>>>>> 436, 437 or 438, > >>>>>>>> then it MUST NOT invoke the verifier for a subsequent request > >>>>>>> This assumes that the verifier is invoked by the UAS, and > >>>>> not by some > >>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier > >>>>>>> in a proxy before the UAS? This rule would forbid that, > >>>>>>> because it would cause that proxy to be call stateful. > >>>>>>> > >>>>>>> I think it would just be better to update the RFC, even > >>>>>>> though that is a bit more trouble than not to. > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>>> on the same > >>>>>>>> dialog unless the From header field URI has changed, and in > >>>>>>> such cases > >>>>>>>> SHOULD NOT make use of the unverified connected-identity. > >>>>>>> Then a UAC, on > >>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>>>>> This would allow > >>>>>>>> business as usual on this dialog (but without the benefit > >>>>>>> of connected > >>>>>>>> identity, therefore no worse than at present). It avoids > >>>>>>> any change to RFC > >>>>>>>> 4474, because verification is optional anyway. > >>>>>>>> > >>>>>>>> Would this work? > >>>>>>>> > >>>>>>>> John > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 > >>>>>>>>> To: Cullen Jennings; Jon Peterson > >>>>>>>>> Cc: SIP; Paul Kyzivat > >>>>>>>>> Subject: FW: Rejecting connected identity (was RE: draft- > >>>>>>>>> ietf-sip-connected-id entity-01 comments) > >>>>>>>>> > >>>>>>>>> Cullen, Jon, > >>>>>>>>> > >>>>>>>>> In case you missed this (it wasn't addressed directly to > >>>>>>>>> you), I would greatly appreciate an opinion from each of > >>>>>>>>> you on this remaining issue in connected-identity. Just to > >>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to > >>>>>>>>> return a 428 response if Identity is missing, but mandates > >>>>>>>>> the sending of a 436, 437 or 438 response for certain > >>>>>>>>> errors arising while verifying the signature. It > seems that > >>>>>>>>> for mid dialog requests this behaviour could be harmful. > >>>>>>>>> What does the UAC for the mid dialog request do if it > >>>>>>>>> receives 436, 437 or 438? If the mid-dialog request was > >>>>>>>>> solely for the purpose of connected identity, it can give > >>>>>>>>> up and allow the call to continue as is. But if the > request > >>>>>>>>> was for some other purpose (e.g., renegotiating the > session > >>>>>>>>> because of hold, say, or session timer refresh), the UAC > >>>>>>>>> really wants it to work. For the normal case where the > >>>>>>>>> Authentication Service is at a proxy, not at the UAC, the > >>>>>>>>> UAC cannot force the Authentication Service to > refrain from > >>>>>>>>> putting this unverifiable signature in the mid-dialog > >>>>>>>>> request, so any attempts to repeat the request would most > >>>>>>>>> likely be doomed to getting the same response. > >>>>>>>>> > >>>>>>>>> It seems there are three things we could do, none very > >>>>> attractive: > >>>>>>>>> 1. Get connected-identity to modify the procedures of RFC > >>>>>>>>> 4474 for a verifier by softening the requirements for > >>>>>>>>> sending 436, 437 and 438 in response to mid-dialog > >>>>>>>>> requests. But then a mid-dialog request from a > rogue source > >>>>>>>>> would be accepted. > >>>>>>>>> 2. Say that the Authentication Service should omit the > >>>>>>>>> signing of mid-dialog requests if a previous attempt has > >>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness > >>>>>>> at the AS. > >>>>>>>>> 3. Accept the fact the mid-dialog requests can fail > in this > >>>>>>>>> way and therefore things like session refresh and session > >>>>>>>>> renegotiation cannot be done, probably resulting in call > >>>>>>>>> failure. Sounds bad, but it is no different from an > initial > >>>>>>>>> INVITE request, where there is nothing the UAC can do if > >>>>>>>>> the AS inserts an Identity header that gets > rejected with 436, > >>>>>>> 437 or 438. > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>> September 2006 19:26 > >>>>>>>>>> To: Elwell, John > >>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: draft- > >>>>>>>>>> ietf-sip-connected-id entity-01 comments) > >>>>>>>>>> > >>>>>>>>>> John, > >>>>>>>>>> > >>>>>>>>>> I want to hear what others, especially Jon and Cullen, > >>>>>>>>>> have to say about this. > >>>>>>>>>> > >>>>>>>>>> It is of some concern to me that a call might fail > >>>>>>> because of some > >>>>>>>>>> problem with the identity mechanism when the same call > >>>>> might have > >>>>>>>>>> succeeded in the absence of any identity. > >>>>>>>>>> > >>>>>>>>>> But possibly the solution to this is policy in the > >>>>>>>>>> implementation of the verifier. What to do in the case of > >>>>>>>>>> the conditions that > >>>>>>>>> lead to these > >>>>>>>>>> errors could be configurable in the verifier: either to > >>>>>>>>> generate the > >>>>>>>>>> error or simply to remove the identity info from the > >>>>>>>>> message. And the > >>>>>>>>>> policy could conceivably vary based on attributes of the > >>>>>>>>>> message, such as whether it is in-dialog or not. > >>>>>>>>>> > >>>>>>>>>> Does it require a change to 4474 to permit that kind > >>> of policy? > >>>>>>>>>> It would be annoying if the end user had no control over > >>>>>>>>>> the insertion and verification of identity, and it > >>>>>>>>>> resulted in calls failing that the user would like to > >>>>>>>>>> permit. But I suppose that is itself > >>>>> a policy > >>>>>>>>>> decision. There are certainly enterprises that want to > >>>>>>>>>> exert that kind of control over what users are permitted > >>>>>>>>>> to do. > >>>>>>>>>> > >>>>>>>>>> Paul > >>>>>>>>>> > >>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>> Paul, > >>>>>>>>>>> > >>>>>>>>>>> I agree with most of your points, and on > reflection I think > >>>>>>>>>> I agree that the > >>>>>>>>>>> solution has to be with the verifier. > >>>>>>>>>>> > >>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 > >>>>>>>>>> 'Use Identity > >>>>>>>>>>> Header' response is concerned, because that is left to > >>>>>>>>>> policy, so we could > >>>>>>>>>>> say in connected-identity that policy should be to not > >>>>> send 428. > >>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>>>>> because RFC 4474 says > >>>>>>>>>>> that they MUST be sent under respective conditions. > >>>>>>>>>> Interestingly, though, > >>>>>>>>>>> there are other failure scenarios that can arise from the > >>>>>>>>>> procedures of > >>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is > >>>>>>>>>> given on how to > >>>>>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>>>>> authoritative for the > >>>>>>>>>>> domain. > >>>>>>>>>>> > >>>>>>>>>>> So one way to solve the present problem would be for the > >>>>>>>>>> connected-identity > >>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case > >>>>>>>>>> of mid-dialog > >>>>>>>>>>> requests. I guess this would mean that it would update RFC > >>>>>>>>>> 4474 as well as > >>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems > >>>>>>>>>> to remove some of > >>>>>>>>>>> the security properties of RFC 4474. > >>>>>>>>>>> > >>>>>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>>>>> responses will be sent, > >>>>>>>>>>> and failure to verify a signature will therefore result in > >>>>>>>>>> inability to > >>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the > >>>>>>>>> UPDATE or > >>>>>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>>>>> session timer refresh > >>>>>>>>>>> or modifying the session, that action will fail. Then the > >>>>>>>>>> call will fail (in > >>>>>>>>>>> the case of inability to refresh the session timer) or > >>>>>>> the session > >>>>>>>>>>> modification will fail. I guess this is somewhat analogous > >>>>>>>>>> to caller ID > >>>>>>>>>>> verification failure in an INVITE request - it is > >>>>>>>>>> impossible to establish a > >>>>>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>>>>> ability to rectify the > >>>>>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>>>>> Authentication Service > >>>>>>>>>>> that puts a rogue Identity header field in every request. > >>>>>>>>>> In the connected > >>>>>>>>>>> identity case, the only difference is that the call is > >>>>>>>>>> already established > >>>>>>>>>>> but is likely to fail if verification fails. > >>>>>>>>>>> > >>>>>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>>>>> wrong source, then > >>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>>>>>>> thing to do, and > >>>>>>>>>>> overriding the verification procedures of RFC 4474 would > >>>>>>>>>> indeed be the wrong > >>>>>>>>>>> thing to do. So perhaps we just have to accept that these > >>>>>>>>>> response codes can > >>>>>>>>>>> be received and will lead to failure. > >>>>>>>>>>> > >>>>>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>>>>> sending a 428 and > >>>>>>>>>>> accept the consequences of other responses that the > >>>>>>>>>> verifier might send. > >>>>>>>>>>> John > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>>>> September 2006 15:13 > >>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] When > >>>>>>>>>>>>>> an Update is sent. Are there any conditions > >>>>> under which > >>>>>>>>>>>>>> it might be rejected. Bad identity for example. I > >>>>>>>>>>>>>> think that > >>>>>>>>>> might need a > >>>>>>>>>>>>>> little discussion and also what the UA does > when it sends > >>>>>>>>>>>> an update > >>>>>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>>>>> situation where it is > >>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>>>>> purposes such as > >>>>>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>>>>> because connected > >>>>>>>>>>>>> identity fails. > >>>>>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>>>>>>>>>> with 428 'Use > >>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>> I'm not sure about this. At the least I think this > >>> one needs > >>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the > >>>>>>>>>>>> conditions when > >>>>>>>>>> it can be > >>>>>>>>>>>> violated. > >>>>>>>>>>>> > >>>>>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>>>>> challenge on an > >>>>>>>>>>>> in-dialog request. In some cases it is the right > >>> thing to do. > >>>>>>>>>>>> A UA that imposes such a requirement will be > >>> limited in what > >>>>>>>>>>>> it can do, but that may still be right in some cases. > >>>>>>>>>>>> > >>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>>>>> Identity header field > >>>>>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>>>>> dialog has resulted in > >>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported > Certificate' or > >>>>>>>>>>>> 438 'Invalid > >>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>> This requirement would force the authentication > service to > >>>>>>>>>> be dialog > >>>>>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>>>>> back into the > >>>>>>>>>>>> sender of the request. This may require a way for the UAC > >>>>>>>>>> to tell the > >>>>>>>>>>>> authentication service not to act. > >>>>>>>>>>>> > >>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>>>>>>>>> results in one of > >>>>>>>>>>>>> these responses if the mid-dialog request was not solely > >>>>>>>>>>>> for the purpose of > >>>>>>>>>>>>> connected identity. If solely for the purpose > of connected > >>>>>>>>>>>> identity there is > >>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take > >>>>>>>>>> any further > >>>>>>>>>>>>> action". > >>>>>>>>>>>> This seems wrong to me. > >>>>>>>>>>>> > >>>>>>>>>>>> I think that the remedy to these is in the > verifier. The > >>>>>>>>>>>> purpose of the verifier is ultimately to drive an > >>>>>>>>>>>> authorization > >>> decision. If > >>>>>>>>>>>> authorization would succeed in the absence of the > >>>>>>>>>> identity, then the > >>>>>>>>>>>> request should be permitted to continue as if the > >>>>>>>>>>>> identity was not present. > >>>>>>>>>>>> > >>>>>>>>>>>> Unfortunately this would seem to require a revision to > >>>>>>>>>>>> 4474 even though the paint is hardly dry on it. > >>>>>>>>>>>> > >>>>>>>>>>>> If this is done, then there is no need of a mechanism to > >>>>>>>>> cause the > >>>>>>>>>>>> authentication service *not* to authenticate. If this is > >>>>>>>>>> *not* done, > >>>>>>>>>>>> then that need remains, which will still require a > >>>>>>>>> change to 4474. > >>>>>>>>>>>> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 11:48:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGE-0002hs-MT; Wed, 11 Oct 2006 11:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGD-0002gS-7H for sip@ietf.org; Wed, 11 Oct 2006 11:44: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 1GXg6M-0007bO-Ah for sip@ietf.org; Wed, 11 Oct 2006 11:34:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2006 08:34:34 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AQAAANerLEWCdYkcAgkOKg X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208,217"; a="345602121:sNHT63694620" 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 k9BFYX5n027926; Wed, 11 Oct 2006 08:34:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9BFYXW4028837; Wed, 11 Oct 2006 08:34:33 -0700 (PDT) Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 08:34:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Oct 2006 08:34:32 -0700 Message-ID: <9AA10AB73EBF3A45ADB921873D8BE953021CE833@xmb-sjc-218.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3263 - Server Usage query Thread-Index: AcbtSr9kKtMXcUnhT7ypmrBVcKHFpA== From: "Sachin Danait \(sdanait\)" To: X-OriginalArrivalTime: 11 Oct 2006 15:34:33.0107 (UTC) FILETIME=[BFFD9E30:01C6ED4A] DKIM-Signature: a=rsa-sha1; q=dns; l=8137; t=1160580873; x=1161444873; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sdanait@cisco.com; z=From:=22Sachin=20Danait=20\(sdanait\)=22=20 |Subject:RFC3263=20-=20Server=20Usage=20query; X=v=3Dcisco.com=3B=20h=3D6H1dBN/KphrKiAh/p+ZEj23WF9Y=3D; b=M9kXxf/lh+FtXJ3LG71qJqORrzWx8mibkkZjdkzoKA45uKgZ5UptgQkAioC5lacND9HcvZEw WwXQ6ZI2KhiqFxNla8tpdM3i1b6h5iHWUuYaV1Yo6jmo3WPwQ9ZNL/Lt; Authentication-Results: sj-dkim-2.cisco.com; header.From=sdanait@cisco.com; dkim=pass ( 65 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: sip@ietf.org Subject: [Sip] RFC3263 - Server Usage query X-BeenThere: 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="===============1238355249==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1238355249== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ED4A.BFCC1113" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ED4A.BFCC1113 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question regarding Section 5 (Server Usage) of RFC3263 that I am requesting your opinion on.=20 =20 IMHO, there appears to be an issue with server-side Via header processing rules as currently specified in RFC 3263, when a Via header of the received request sent-by address field has an SRV name (a port is not specified on the header) and the SRV name resolves to non-default SIP ports. =20 Section 5 of RFC3263 references section 18.2.2 of RFC3261, and states that for unreliable transports, the initial response transmission sent by a UAS should be attempted towards the source address of the received request and the default destination port (5060) if none is specified in the Via header. If this initial response encounters a failure and there wasn't any port specified in the Via, the UAS should resolve the domain name in the sent-by field using SRV procedures, and the response should be sent to the address and port selected based on that SRV query. =20 My question is regarding the first step of the above response processing logic.=20 =20 Since SRV lookups are performed on a domain-name only when no port is specified, this obligates the sender of a request to not encode a port in its Via header if that sender wishes to be reachable using SRV resolution. Consequently, this appears to imply that the sender needs to be listening for responses on the default SIP port in addition to any of the ports resolved from the SRV query, since the first transmission of any incoming response will always be directed towards the default port as per section 18.2.2 of RFC3261. =20 =20 As I understand it, based on how this rule is currently worded, if none of the SRV resolutions of Via Sent-By domain-name resolve to port 5060 AND if a UAC is not listening for responses on port 5060, the initial transmission of every response will always encounter a failure before resorting to SRV procedures. =20 thanks, -Sachin =20 ------_=_NextPart_001_01C6ED4A.BFCC1113 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question regarding Section 5 (Server Usage) = of RFC3263 that I am requesting your opinion on. =

 

IMHO, there appears to be an issue with server-side = Via header processing rules as currently specified in RFC 3263, when a Via = header of the received request sent-by address field has an SRV name (a port is = not specified on the header) and the SRV name resolves to non-default SIP = ports.

 

Section 5 of RFC3263 references section 18.2.2 of = RFC3261, and states that for unreliable transports, the initial response transmission = sent by a UAS should be attempted towards the source address of the received = request and the default destination port (5060) if none is specified in the Via = header. If this initial response encounters a failure and there wasn’t any = port specified in the Via, the UAS should resolve the domain name in the = sent-by field using SRV procedures, and the response should be sent to the = address and port selected based on that SRV query.

 

My question is regarding the first step of the above response processing logic.

 

Since SRV lookups are performed on a domain-name only = when no port is specified, this obligates the sender of a request to not = encode a port in its Via header if that sender wishes to be reachable using SRV resolution. Consequently, this appears to imply that the sender needs to = be listening for responses on the default SIP port in addition to any of = the ports resolved from the SRV query, since the first transmission of any = incoming response will always be directed towards the default port as per section = 18.2.2 of RFC3261. 

 

As I understand it, based on how this rule is = currently worded, if none of the SRV resolutions of Via Sent-By domain-name resolve to = port 5060  AND if a UAC is not listening for responses on port 5060, the initial = transmission of every response will always encounter a failure before resorting to = SRV procedures.

 

thanks,

-Sachin

 

------_=_NextPart_001_01C6ED4A.BFCC1113-- --===============1238355249== 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 --===============1238355249==-- From sip-bounces@ietf.org Wed Oct 11 12:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgbk-0006R1-AI; Wed, 11 Oct 2006 12:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgbi-0006Qw-GK for sip@ietf.org; Wed, 11 Oct 2006 12:06:58 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXgbh-00045m-8I for sip@ietf.org; Wed, 11 Oct 2006 12:06:58 -0400 X-VirusChecked: Checked X-Env-Sender: chinmay.dhodapkar@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1160582815!9850861!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 5442 invoked from network); 11 Oct 2006 16:06:56 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-6.tower-119.messagelabs.com with SMTP; 11 Oct 2006 16:06:56 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id k9BG6t10027732 for ; Wed, 11 Oct 2006 09:06:55 -0700 (MST) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k9BG6sum011366 for ; Wed, 11 Oct 2006 11:06:55 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Oct 2006 12:06:53 -0400 Message-ID: <39AF6C705C49BB458D2E00C74D963DB2018AE28D@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changing SSRC/sequence numbers during a call thread-index: AcbtT0StiHn+TzhES4S8s5Y5G+np0A== From: "Dhodapkar Chinmay-C23627" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Sip] Changing SSRC/sequence numbers during a call X-BeenThere: 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="===============1717311123==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1717311123== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ED4F.45061F31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6ED4F.45061F31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Can the SSRC of RTP packets change midway between the call. The scenario is that the call has been set up using the usual SIP/SDP signalling. After this there is no further signalling between the two entities, but the SSRC changes. Is this valid? Since nothing else changed (remote ip/port,=20 remote entity, there is no conflict of SSRCs, etc). =20 Looking forward to some inputs on this. Regards, Chinmay Dhodapkar =20 ------_=_NextPart_001_01C6ED4F.45061F31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Can = the SSRC of RTP=20 packets change midway between the call. The scenario is that = the call has=20 been set up using the usual SIP/SDP signalling.
After = this there is=20 no further signalling between the two entities, but the SSRC changes. Is = this=20 valid? Since nothing else changed (remote ip/port,
remote = entity, there=20 is no conflict of SSRCs, etc).
 
Looking forward to=20 some inputs on this.
Regards,
Chinmay=20 Dhodapkar
 
------_=_NextPart_001_01C6ED4F.45061F31-- --===============1717311123== 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 --===============1717311123==-- From sip-bounces@ietf.org Wed Oct 11 12:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhNk-0007IG-7s; Wed, 11 Oct 2006 12:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhNh-0007EO-OZ for sip@ietf.org; Wed, 11 Oct 2006 12:56:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhNd-0002IV-Vx for sip@ietf.org; Wed, 11 Oct 2006 12:56:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2006 09:56:28 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="330562662:sNHT99362208" 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 k9BGuSTD015121; Wed, 11 Oct 2006 09:56:28 -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 k9BGuSOV012627; Wed, 11 Oct 2006 09:56:28 -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, 11 Oct 2006 12:56:27 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 12:56:27 -0400 Message-ID: <452D223A.8080403@cisco.com> Date: Wed, 11 Oct 2006 12:56:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> <452B9E1C.4030804@cisco.com> <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> In-Reply-To: <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Oct 2006 16:56:27.0287 (UTC) FILETIME=[3111FA70:01C6ED56] DKIM-Signature: a=rsa-sha1; q=dns; l=24588; t=1160585788; x=1161449788; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments); X=v=3Dcisco.com=3B=20h=3DxFpxC1XNdmtl1r/DEf+C1Z0YsQs=3D; b=uKmSJMAl8HgrMrA5FVdhkPc9u1fUwLWmzBC0LSAE8tPazBo6N+T/plQvhYdh4CLOeqesawQk +hsUeRcw0FDQxMSaTO4OSP7QExMCndIh2/O6nuPhsrjEoAlwzL2p8sFB; 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: b271b9c4fc51b08326fa0949e61c0156 Cc: SIP , "Elwell, John" , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > > I'm generally on board with things like you are suggesting below and > what is suggested in draft-rosenberg-sip-identity-coexistence. However, > I want to think very carefully about the security properties of not > rejecting things that failed based on security properties - I'm not sure > what I think of this yet. > > Any time you allow a security action that failed to continue sending the > request downstream, you run the risk that something further down stream > assumes that the security action worked because it must have happened > upstream. Clearly from a security point of view it would be better not > to have upstream elements do the security validation for a downstream > element but we did decide long ago that when doing Identity we were > going to allow for this so that we could migrate from UAs that do not > support Identity to system that does. > > So let me flip this around the other way and ask - do we really need to > allow for a request that failed verification to not result in an error? I think the poster child for this is when the error is 437 Unsupported Certificate. In this case the caller may be trapped. It has an identity service it can't control, that unconditionally adds an identity. And then the callee has an authentication verifier in front of it. As things stand, that verifier is required to reject requests with certs it doesn't understand, even in cases where it will permit requests with no identity at all. Paul > Are there use cases where the verification would fail and we really do > want to continue with the message? If these cases would only happen in a > fairly broken system, then it might not be worth the security problems > they would cause. I don't know what I think but I am interested in where > we might need this and if there might be other ways to skin the cat in > those situations. > > Cullen > > > On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > >> John, >> >> What you outline below is exactly what I had in mind. >> >> Paul >> >> Elwell, John wrote: >>> Paul, >>> Dan Wing made a suggestion that P-Asserted-Identity would fulfil your >>> requirement. I guess it would work like this. >>> A Verifier not located at the UAS would attempt to verify the >>> signature in >>> the Identity header field. >>> - Case A - verification succeeds. The Verifier inserts into the >>> forwarded >>> request a P-Asserted-Identity header field containing the verified >>> URI (from >>> the From header field) in the forwarded request. The Identity and >>> Identity-Info header fields will still be present and available should >>> another verifier be encountered downstream. >>> - Case B - verification fails but request not rejected. The verifier is >>> unable to verify (e.g., because it can't dereference the URL) but >>> according >>> to policy does not reject the request. It simply forwards the request >>> as is. >>> If there is a further verifier downstream, that too can attempt to >>> verify >>> the signature. >>> - Case C - verification fails but request is rejected. The verifier is >>> unable to verify (e.g., bad signature) and according to policy it >>> rejects >>> the request. >>> A UAS that does not contain a verifier can simply use >>> P-Asserted-Identity, >>> if present. >>> This seems to have some synergy with >>> draft-rosenberg-sip-identity-coexistence. In fact the relaxation of >>> rules >>> concerning rejection by a verifier that is unable to verify a signature >>> might be beneficial to that proposal. >>> I will omit discussion of the mechanics of documentation until I see >>> what >>> reaction there is to the technical proposal. >>> John >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October 2006 >>>> 13:54 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>> >>>> >>>> >>>> Elwell, John wrote: >>>>> Paul, >>>>> >>>>> Your message arrived just after I had submitted 02, so your >>>> comments are not >>>>> taken into account in that version. However, I felt it was >>>> useful to get 02 >>>>> out as a baseline for further discussion. >>>> Sure. I too am interested in seeing other inputs on this subject. >>>> >>>>> It seems the remaining issue is whether to add an explicit >>>> indication of >>>>> removal of the Identity header field by a verifier that has >>>> been unable to >>>>> verify the signature. Whilst this may make sense, I am >>>> concerned it starts >>>>> to go beyond the scope of connected-identity, so I would like other >>>>> opinions, especially from the chairs and from the authors >>>> of Identity. >>>> >>>> Rather than adding something to indicate that identity has been >>>> *removed* due to failure to verify, I am advocating adding something >>>> to indicate that verification has *succeeded*, while leaving the >>>> identity header in place. In this way, a downstream element may >>>> *either* trust the info added by the verifier or do its own >>>> verification of the identity header. >>>> >>>> Of course this is only significant if the verifier is doing work for >>>> downstream elements, and not for itself. >>>> >>>> Paul >>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 05 October >>>>>> 2006 16:29 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>> >>>>>> >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Paul, >>>>>>> >>>>>>> So your proposal is that the connected-identity RFC should >>>>>> update RFC 4474 >>>>>>> to somehow relax rules at a verifier. Correct? >>>>>> Yeah, I think so. >>>>>> >>>>>>> So the next question concerns the way in which these >>>> rules should be >>>>>>> relaxed. One problem with the verifier not being located at >>>>>> the UAS but at >>>>>>> some proxy is that the UAS might be configured always to >>>>>> trust identities >>>>>>> received in requests via the verifier's proxy if an >>>>>> Identity header field is >>>>>>> present, on the assumption that the signature has been >>>>>> checked by the >>>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>>> not reject a >>>>>>> request with a bad signature, should remove the Identity >>>>>> header field (and >>>>>>> also Identity-Info) before forwarding the request towards >>>>>> the target. >>>>>> >>>>>> (I think I have seen someone propose combining the use of Identity >>>>>> and P-Asserted-Identity, though I don't recall the details, or >>>>>> which draft it was. So what I am about to say might bear no >>>> relationship to that.) >>>>>> I could see how Identity might be used between trust >>>> domains, while >>>>>> P-Asserted-Identity is used within a trust domain. In that case, a >>>>>> verifier might run at the entry point to a trust domain and if >>>>>> verification succeeds, insert a P-Asserted-Identity header with a >>>>>> corresponding identity. It then might, or might not, remove the >>>>>> Identity header. Recipients within the trust domain could then use >>>>>> P-Asserted-Identity as the source of identity info. (In this >>>>>> scenario, an identity header would only be added to requests when >>>>>> they leave the trust domain.) >>>>>> >>>>>> In this kind of environment, it is only necessary for the >>>> verifier to >>>>>> omit the P-Asserted-Identity header when verification fails. >>>>>> >>>>>>> Under what conditions should a verifier remove an Identity >>>>>> header field >>>>>>> rather than rejecting with 436/437/438? My inclination >>>>>> would be to leave it >>>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>>> concerned, and >>>>>>> then make more precise statements concerning mid-dialog requests. >>>>>>> Alternatively the update to RFC 4474 could just relax the >>>> rules for >>>>>>> mid-dialog requests. I think there is some merit in >>>>>> relaxing the rules in >>>>>>> general, because otherwise there might be situations where >>>>>> a legitimate >>>>>>> caller cannot establish a call because an Authentication >>>>>> Service (outside >>>>>>> the UAC's control) is inserting an unverifiable signature >>>> (e.g., in >>>>>>> Identity-Info placing a URL that the Verifier cannot >>>>>> dereference for some >>>>>>> reason). >>>>>> What you say sounds reasonable to me. >>>>>> >>>>>> There is however some risk to having a verifier remove >>>> identity. The >>>>>> problem would be when there are potentially multiple >>>> verifiers that >>>>>> don't trust one another. If an early one removes the >>>> header, then it >>>>>> prevents a subsequent verifier from doing its own verification. >>>>>> >>>>>> This could come up if a request transits a domain on the way to >>>>>> another domain. Each domain may wish to do its own verification. >>>>>> >>>>>> That is an advantage to having the verifier add something to the >>>>>> request to indicate the result of its verification. >>>>>> >>>>>>> One consequence of the Verifier being separated from the >>>>>> UAS is that we >>>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>>> its proxy (for >>>>>>> similar reasons that you cited for the Authentication >>>>>> Service earlier). So >>>>>>> for mid-dialog requests we would need to mandate, or at >>>>>> least recommend, >>>>>>> that 436/437/438 should not be sent. >>>>>> Right. >>>>>> >>>>>> Paul >>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 October >>>>>>>> 2006 01:44 >>>>>>>> To: Elwell, John >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Elwell, John wrote: >>>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>>> >>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>>> 436, 437 or 438, >>>>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>>> not by some >>>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier in >>>>>>>> a proxy before the UAS? This rule would forbid that, because it >>>>>>>> would cause that proxy to be call stateful. >>>>>>>> >>>>>>>> I think it would just be better to update the RFC, even though >>>>>>>> that is a bit more trouble than not to. >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> on the same >>>>>>>>> dialog unless the From header field URI has changed, and in >>>>>>>> such cases >>>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>>> Then a UAC, on >>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>>> This would allow >>>>>>>>> business as usual on this dialog (but without the benefit >>>>>>>> of connected >>>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>>> any change to RFC >>>>>>>>> 4474, because verification is optional anyway. >>>>>>>>> >>>>>>>>> Would this work? >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 >>>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>> >>>>>>>>>> Cullen, Jon, >>>>>>>>>> >>>>>>>>>> In case you missed this (it wasn't addressed directly to you), >>>>>>>>>> I would greatly appreciate an opinion from each of you on this >>>>>>>>>> remaining issue in connected-identity. Just to summarise, RFC >>>>>>>>>> 4474 leaves it up to policy whether to return a 428 response >>>>>>>>>> if Identity is missing, but mandates the sending of a 436, 437 >>>>>>>>>> or 438 response for certain errors arising while verifying the >>>>>>>>>> signature. It seems that for mid dialog requests this >>>>>>>>>> behaviour could be harmful. What does the UAC for the mid >>>>>>>>>> dialog request do if it receives 436, 437 or 438? If the >>>>>>>>>> mid-dialog request was solely for the purpose of connected >>>>>>>>>> identity, it can give up and allow the call to continue as is. >>>>>>>>>> But if the request was for some other purpose (e.g., >>>>>>>>>> renegotiating the session because of hold, say, or session >>>>>>>>>> timer refresh), the UAC really wants it to work. For the >>>>>>>>>> normal case where the Authentication Service is at a proxy, >>>>>>>>>> not at the UAC, the UAC cannot force the Authentication >>>>>>>>>> Service to refrain from putting this unverifiable signature in >>>>>>>>>> the mid-dialog request, so any attempts to repeat the request >>>>>>>>>> would most likely be doomed to getting the same response. >>>>>>>>>> >>>>>>>>>> It seems there are three things we could do, none very >>>>>> attractive: >>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC 4474 >>>>>>>>>> for a verifier by softening the requirements for sending 436, >>>>>>>>>> 437 and 438 in response to mid-dialog requests. But then a >>>>>>>>>> mid-dialog request from a rogue source would be accepted. >>>>>>>>>> 2. Say that the Authentication Service should omit the signing >>>>>>>>>> of mid-dialog requests if a previous attempt has resulted in >>>>>>>>>> 436, 437 or 438. But this implies statefulness >>>>>>>> at the AS. >>>>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>>>> way and therefore things like session refresh and session >>>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>>>>>> AS inserts an Identity header that gets rejected with 436, >>>>>>>> 437 or 438. >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>> September 2006 19:26 >>>>>>>>>>> To: Elwell, John >>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>> >>>>>>>>>>> John, >>>>>>>>>>> >>>>>>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>>>>>> to say about this. >>>>>>>>>>> >>>>>>>>>>> It is of some concern to me that a call might fail >>>>>>>> because of some >>>>>>>>>>> problem with the identity mechanism when the same call >>>>>> might have >>>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>>> >>>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>>> implementation of the verifier. What to do in the case of the >>>>>>>>>>> conditions that >>>>>>>>>> lead to these >>>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>>> generate the >>>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>>> message. And the >>>>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>>>> message, such as whether it is in-dialog or not. >>>>>>>>>>> >>>>>>>>>>> Does it require a change to 4474 to permit that kind >>>> of policy? >>>>>>>>>>> It would be annoying if the end user had no control over the >>>>>>>>>>> insertion and verification of identity, and it resulted in >>>>>>>>>>> calls failing that the user would like to permit. But I >>>>>>>>>>> suppose that is itself >>>>>> a policy >>>>>>>>>>> decision. There are certainly enterprises that want to exert >>>>>>>>>>> that kind of control over what users are permitted to do. >>>>>>>>>>> >>>>>>>>>>> Paul >>>>>>>>>>> >>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>> Paul, >>>>>>>>>>>> >>>>>>>>>>>> I agree with most of your points, and on reflection I think >>>>>>>>>>> I agree that the >>>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>>> >>>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>>>> 'Use Identity >>>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>>> policy, so we could >>>>>>>>>>>> say in connected-identity that policy should be to not >>>>>> send 428. >>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>>> because RFC 4474 says >>>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>>> Interestingly, though, >>>>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>>>> procedures of >>>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>>>> given on how to >>>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>>> authoritative for the >>>>>>>>>>>> domain. >>>>>>>>>>>> >>>>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>>>> connected-identity >>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>>>> of mid-dialog >>>>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>>>> 4474 as well as >>>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>>>> to remove some of >>>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>>> >>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>>> responses will be sent, >>>>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>>>> inability to >>>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>>>> UPDATE or >>>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>>> session timer refresh >>>>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>>>> call will fail (in >>>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>>> the session >>>>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>>>> to caller ID >>>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>>> impossible to establish a >>>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>>> ability to rectify the >>>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>>> Authentication Service >>>>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>>>> In the connected >>>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>>> already established >>>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>>> >>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>>> wrong source, then >>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>>>> thing to do, and >>>>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>>>> indeed be the wrong >>>>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>>>> response codes can >>>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>>> >>>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>>> sending a 428 and >>>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>>> verifier might send. >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>> September 2006 15:13 >>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] When an >>>>>>>>>>>>>>> Update is sent. Are there any conditions >>>>>> under which >>>>>>>>>>>>>>> it might be rejected. Bad identity for example. I think >>>>>>>>>>>>>>> that >>>>>>>>>>> might need a >>>>>>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>>>>>> an update >>>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>>> situation where it is >>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>>> purposes such as >>>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>>> because connected >>>>>>>>>>>>>> identity fails. >>>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>> I'm not sure about this. At the least I think this >>>> one needs >>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the >>>>>>>>>>>>> conditions when >>>>>>>>>>> it can be >>>>>>>>>>>>> violated. >>>>>>>>>>>>> >>>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>>> challenge on an >>>>>>>>>>>>> in-dialog request. In some cases it is the right >>>> thing to do. >>>>>>>>>>>>> A UA that imposes such a requirement will be >>>> limited in what >>>>>>>>>>>>> it can do, but that may still be right in some cases. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>>> Identity header field >>>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>> This requirement would force the authentication service to >>>>>>>>>>> be dialog >>>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>>> back into the >>>>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>>>> to tell the >>>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>>>> results in one of >>>>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>>>> for the purpose of >>>>>>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>>>>>> identity there is >>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>>>> any further >>>>>>>>>>>>>> action". >>>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>>> >>>>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>>>> purpose of the verifier is ultimately to drive an >>>>>>>>>>>>> authorization >>>> decision. If >>>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>>> identity, then the >>>>>>>>>>>>> request should be permitted to continue as if the identity >>>>>>>>>>>>> was not present. >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunately this would seem to require a revision to 4474 >>>>>>>>>>>>> even though the paint is hardly dry on it. >>>>>>>>>>>>> >>>>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>>>> cause the >>>>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>>>> *not* done, >>>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>>> change to 4474. >>>>>>>>>>>>> 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 14:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXid4-000828-BE; Wed, 11 Oct 2006 14:16:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXid2-00081x-VX for sip@ietf.org; Wed, 11 Oct 2006 14:16:28 -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 1GXid0-0001x4-Bx for sip@ietf.org; Wed, 11 Oct 2006 14:16:28 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9BIGMro011184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Oct 2006 13:16:22 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <45248E06.305@cisco.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@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: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Wed, 11 Oct 2006 13:16:21 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Cullen Jennings , SIP , Pete Cordell , 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 So, I read this to say the proposed recommendation of CRC32 as specified in rfc3309 is ok to go forward with. Based on the discussion, I think I will also point out that MD5 can be used (and has been used in the past), that its use would rely only on its collision properties, not any cryptographic properties, and point out that it is much slower than the alternative above. Any objection? RjS On Oct 4, 2006, at 11:45 PM, Michael Thomas wrote: > Cullen Jennings wrote: > >>> >>> The only knock in my mind is that it may be slower than >>> something else, >> >> >> Yes - I should have been clearer - that was my only concern. And >> even with that, I've never been a believer that the performance >> mattered much but many people in the WG have expressed that we >> have to do O (N^2) where N=30 or 70 depending on who you follow >> and this was a huge deal. I just wanted to take this performance >> argument off the table. > > > It's probably not worth belaboring this too much, but I do worry > about not > constraining this such that roll your own is a likely outcome. > Which is why > I said that a SHOULD strength algorithm(s) seems pretty reasonable. > >> >>> but I'd >>> worry a great deal about the "something else" if collisions are >>> a problem. Just randomly >>> inventing a good hashing algorithm with good collision >>> properties especially with >>> similar chosen text is not exactly the easiest thing to do. >> >> >> 100% agree - I'm not a fan of roll your own solution to hashes. >> Actually people still make fun of me for a project where I created >> in a hash table that only generated even numbers. Since then I >> have always been concerned about getting burned from things I >> rolled myself. > > hmm, malloc (tablesize/2); hashvalue /= 2; and it's all of a sudden > not so > embarassing :) > >> >> >>> Since you're relying on this >>> for carrying state, I think it's a bad idea to not at least do a >>> SHOULD level algorithm(s) >>> and be very certain that the algorithm you choose actual has the >>> collision resistance >>> needed. I'm not an expert here by any means, but my recollection >>> is that CRC does >>> NOT have very good properties that way. >> >> >> CRC has poor whitening characteristics but it collision >> distribution if fairly uniform. All of this is weighted off >> against how many bits collision detection do we use. Keep in min >> that we have up to 70 things that we don't want to collide with a >> something like 1 in fives nines probability of collision. WIth a >> good hash we could likely do this in something like 15 bits >> (WAG), with a crappy hash we need a few more bits. We are talking >> about using insanely more bits than this (32 bits) so I'm not >> that worried. I would be worried with a CRC16. Also, as you point >> out, we are not trying to protect against a case where an >> attacker deliberately generates a collision in which case CRC >> would be a very bad choice. > > > I'm good for whatever is appropriate here -- my main point is > that using things > like md5 for non-crypto strength hashes shouldn't be dismissed if > you're using > it just as a _hash_ algorithm. And if that causes knee-jerks on > the IESG, etc, it > would be good to get that out of the way. My suspicion is that it > wouldn't though > once it was clear that it was just being used as a hash for non- > crypto reasons. > > Mike, rehabilitaton-R-us. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 11 15:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjfX-0007fP-SI; Wed, 11 Oct 2006 15:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjfW-0007fK-Jg for sip@ietf.org; Wed, 11 Oct 2006 15:23:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjfV-0005iY-BW for sip@ietf.org; Wed, 11 Oct 2006 15:23:06 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2006 12:23:05 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="330624294:sNHT56188816" 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 k9BJN49k021628; Wed, 11 Oct 2006 12:23:04 -0700 Received: from [192.168.1.3] (sjc-vpn5-444.cisco.com [10.21.89.188]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9BJN4OV028820; Wed, 11 Oct 2006 12:23:04 -0700 (PDT) In-Reply-To: References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B7852C4-A44B-4C3F-B253-3FDC5CD856FB@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Wed, 11 Oct 2006 12:22:58 -0700 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=378; t=1160594584; x=1161458584; 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]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DAyadtlHzVE2lqPGk6mddYA9NTlg=3D; b=U/P8iN5Uk7YEX3qiEmuud1g82YdXamZw3sHVzPMIFALqV5f+2h3v70F0IkWhKNlDhk7+fDhM 5MG72w2aNAtxklup27Am/+fAsMB5gKyC1CxEUSvRTx3g+CwBHb5qpDsW; 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIP , Michael Thomas , Pete Cordell , 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 Oct 11, 2006, at 11:16 AM, Robert Sparks wrote: > Based on the discussion, I think I will also point out that MD5 can > be used (and has been used in the past), > that its use would rely only on its collision properties, not any > cryptographic properties, and point out that it > is much slower than the alternative above. > > Any objection? works for me _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 15:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkCg-0008Nf-D2; Wed, 11 Oct 2006 15:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkCe-0008NQ-F1 for sip@ietf.org; Wed, 11 Oct 2006 15:57:20 -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 1GXkCJ-0000Su-7C for sip@ietf.org; Wed, 11 Oct 2006 15:57:20 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0J6Z00M01M2Z2A@siemenscomms.co.uk> for sip@ietf.org; Wed, 11 Oct 2006 20:56:59 +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 <0J6Z00J8JM2YVP@siemenscomms.co.uk>; Wed, 11 Oct 2006 20:56:58 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <4D9SWAR9>; Wed, 11 Oct 2006 20:56:46 +0100 Content-return: allowed Date: Wed, 11 Oct 2006 20:56:45 +0100 From: "Elwell, John" Subject: RE: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) To: Paul Kyzivat , Cullen Jennings Message-id: <50B1CBA96870A34799A506B2313F26670A11F96A@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: c11d54fae0b5a4f2b2d9ece4929bab8a Cc: SIP , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 11 October 2006 17:56 > To: Cullen Jennings > Cc: Elwell, John; Jon Peterson; SIP; Dan Wing; Jonathan Rosenberg > Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > draft-ietf-si p-connecte d-id entity-01 comments) > > > > Cullen Jennings wrote: > > > > I'm generally on board with things like you are suggesting > below and > > what is suggested in > draft-rosenberg-sip-identity-coexistence. However, > > I want to think very carefully about the security properties of not > > rejecting things that failed based on security properties - > I'm not sure > > what I think of this yet. > > > > Any time you allow a security action that failed to > continue sending the > > request downstream, you run the risk that something further > down stream > > assumes that the security action worked because it must > have happened > > upstream. Clearly from a security point of view it would be > better not > > to have upstream elements do the security validation for a > downstream > > element but we did decide long ago that when doing Identity we were > > going to allow for this so that we could migrate from UAs > that do not > > support Identity to system that does. > > > > So let me flip this around the other way and ask - do we > really need to > > allow for a request that failed verification to not result > in an error? > > I think the poster child for this is when the error is 437 > Unsupported > Certificate. > > In this case the caller may be trapped. It has an identity service it > can't control, that unconditionally adds an identity. And then the > callee has an authentication verifier in front of it. As > things stand, > that verifier is required to reject requests with certs it doesn't > understand, even in cases where it will permit requests with > no identity > at all. [JRE] Equally 436 is difficult. An Identity Service the caller can't control is inserting a signature based on a certificate that a verifier that the callee can't control can't dereference. IMO, the only response code in RFC 4474 that perhaps does justify an unconditional MUST is 438. John > > Paul > > > Are there use cases where the verification would fail and > we really do > > want to continue with the message? If these cases would > only happen in a > > fairly broken system, then it might not be worth the > security problems > > they would cause. I don't know what I think but I am > interested in where > > we might need this and if there might be other ways to skin > the cat in > > those situations. > > > > Cullen > > > > > > On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > > > >> John, > >> > >> What you outline below is exactly what I had in mind. > >> > >> Paul > >> > >> Elwell, John wrote: > >>> Paul, > >>> Dan Wing made a suggestion that P-Asserted-Identity would > fulfil your > >>> requirement. I guess it would work like this. > >>> A Verifier not located at the UAS would attempt to verify the > >>> signature in > >>> the Identity header field. > >>> - Case A - verification succeeds. The Verifier inserts into the > >>> forwarded > >>> request a P-Asserted-Identity header field containing the > verified > >>> URI (from > >>> the From header field) in the forwarded request. The Identity and > >>> Identity-Info header fields will still be present and > available should > >>> another verifier be encountered downstream. > >>> - Case B - verification fails but request not rejected. > The verifier is > >>> unable to verify (e.g., because it can't dereference the URL) but > >>> according > >>> to policy does not reject the request. It simply forwards > the request > >>> as is. > >>> If there is a further verifier downstream, that too can > attempt to > >>> verify > >>> the signature. > >>> - Case C - verification fails but request is rejected. > The verifier is > >>> unable to verify (e.g., bad signature) and according to policy it > >>> rejects > >>> the request. > >>> A UAS that does not contain a verifier can simply use > >>> P-Asserted-Identity, > >>> if present. > >>> This seems to have some synergy with > >>> draft-rosenberg-sip-identity-coexistence. In fact the > relaxation of > >>> rules > >>> concerning rejection by a verifier that is unable to > verify a signature > >>> might be beneficial to that proposal. > >>> I will omit discussion of the mechanics of documentation > until I see > >>> what > >>> reaction there is to the technical proposal. > >>> John > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 > October 2006 > >>>> 13:54 > >>>> To: Elwell, John > >>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>> > >>>> > >>>> > >>>> Elwell, John wrote: > >>>>> Paul, > >>>>> > >>>>> Your message arrived just after I had submitted 02, so your > >>>> comments are not > >>>>> taken into account in that version. However, I felt it was > >>>> useful to get 02 > >>>>> out as a baseline for further discussion. > >>>> Sure. I too am interested in seeing other inputs on this subject. > >>>> > >>>>> It seems the remaining issue is whether to add an explicit > >>>> indication of > >>>>> removal of the Identity header field by a verifier that has > >>>> been unable to > >>>>> verify the signature. Whilst this may make sense, I am > >>>> concerned it starts > >>>>> to go beyond the scope of connected-identity, so I > would like other > >>>>> opinions, especially from the chairs and from the authors > >>>> of Identity. > >>>> > >>>> Rather than adding something to indicate that identity has been > >>>> *removed* due to failure to verify, I am advocating > adding something > >>>> to indicate that verification has *succeeded*, while leaving the > >>>> identity header in place. In this way, a downstream element may > >>>> *either* trust the info added by the verifier or do its own > >>>> verification of the identity header. > >>>> > >>>> Of course this is only significant if the verifier is > doing work for > >>>> downstream elements, and not for itself. > >>>> > >>>> Paul > >>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: > 05 October > >>>>>> 2006 16:29 > >>>>>> To: Elwell, John > >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Elwell, John wrote: > >>>>>>> Paul, > >>>>>>> > >>>>>>> So your proposal is that the connected-identity RFC should > >>>>>> update RFC 4474 > >>>>>>> to somehow relax rules at a verifier. Correct? > >>>>>> Yeah, I think so. > >>>>>> > >>>>>>> So the next question concerns the way in which these > >>>> rules should be > >>>>>>> relaxed. One problem with the verifier not being located at > >>>>>> the UAS but at > >>>>>>> some proxy is that the UAS might be configured always to > >>>>>> trust identities > >>>>>>> received in requests via the verifier's proxy if an > >>>>>> Identity header field is > >>>>>>> present, on the assumption that the signature has been > >>>>>> checked by the > >>>>>>> verifier. Therefore it sounds like the verifier, if it does > >>>>>> not reject a > >>>>>>> request with a bad signature, should remove the Identity > >>>>>> header field (and > >>>>>>> also Identity-Info) before forwarding the request towards > >>>>>> the target. > >>>>>> > >>>>>> (I think I have seen someone propose combining the use > of Identity > >>>>>> and P-Asserted-Identity, though I don't recall the details, or > >>>>>> which draft it was. So what I am about to say might bear no > >>>> relationship to that.) > >>>>>> I could see how Identity might be used between trust > >>>> domains, while > >>>>>> P-Asserted-Identity is used within a trust domain. In > that case, a > >>>>>> verifier might run at the entry point to a trust domain and if > >>>>>> verification succeeds, insert a P-Asserted-Identity > header with a > >>>>>> corresponding identity. It then might, or might not, > remove the > >>>>>> Identity header. Recipients within the trust domain > could then use > >>>>>> P-Asserted-Identity as the source of identity info. (In this > >>>>>> scenario, an identity header would only be added to > requests when > >>>>>> they leave the trust domain.) > >>>>>> > >>>>>> In this kind of environment, it is only necessary for the > >>>> verifier to > >>>>>> omit the P-Asserted-Identity header when verification fails. > >>>>>> > >>>>>>> Under what conditions should a verifier remove an Identity > >>>>>> header field > >>>>>>> rather than rejecting with 436/437/438? My inclination > >>>>>> would be to leave it > >>>>>>> as a matter of policy as far as the update to RFC 4474 is > >>>>>> concerned, and > >>>>>>> then make more precise statements concerning > mid-dialog requests. > >>>>>>> Alternatively the update to RFC 4474 could just relax the > >>>> rules for > >>>>>>> mid-dialog requests. I think there is some merit in > >>>>>> relaxing the rules in > >>>>>>> general, because otherwise there might be situations where > >>>>>> a legitimate > >>>>>>> caller cannot establish a call because an Authentication > >>>>>> Service (outside > >>>>>>> the UAC's control) is inserting an unverifiable signature > >>>> (e.g., in > >>>>>>> Identity-Info placing a URL that the Verifier cannot > >>>>>> dereference for some > >>>>>>> reason). > >>>>>> What you say sounds reasonable to me. > >>>>>> > >>>>>> There is however some risk to having a verifier remove > >>>> identity. The > >>>>>> problem would be when there are potentially multiple > >>>> verifiers that > >>>>>> don't trust one another. If an early one removes the > >>>> header, then it > >>>>>> prevents a subsequent verifier from doing its own verification. > >>>>>> > >>>>>> This could come up if a request transits a domain on > the way to > >>>>>> another domain. Each domain may wish to do its own > verification. > >>>>>> > >>>>>> That is an advantage to having the verifier add > something to the > >>>>>> request to indicate the result of its verification. > >>>>>> > >>>>>>> One consequence of the Verifier being separated from the > >>>>>> UAS is that we > >>>>>>> don't want to rely on stateful behaviour at the Verifier or > >>>>>> its proxy (for > >>>>>>> similar reasons that you cited for the Authentication > >>>>>> Service earlier). So > >>>>>>> for mid-dialog requests we would need to mandate, or at > >>>>>> least recommend, > >>>>>>> that 436/437/438 should not be sent. > >>>>>> Right. > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>>> John > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: > 03 October > >>>>>>>> 2006 01:44 > >>>>>>>> To: Elwell, John > >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Elwell, John wrote: > >>>>>>>>> Thinking further on this, perhaps there is a 4th way: > >>>>>>>>> > >>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>>>>>> 436, 437 or 438, > >>>>>>>>> then it MUST NOT invoke the verifier for a > subsequent request > >>>>>>>> This assumes that the verifier is invoked by the UAS, and > >>>>>> not by some > >>>>>>>> proxy in front of the UAS. Isn't it valid to have a > verifier in > >>>>>>>> a proxy before the UAS? This rule would forbid that, > because it > >>>>>>>> would cause that proxy to be call stateful. > >>>>>>>> > >>>>>>>> I think it would just be better to update the RFC, > even though > >>>>>>>> that is a bit more trouble than not to. > >>>>>>>> > >>>>>>>> Paul > >>>>>>>> > >>>>>>>>> on the same > >>>>>>>>> dialog unless the From header field URI has changed, and in > >>>>>>>> such cases > >>>>>>>>> SHOULD NOT make use of the unverified connected-identity. > >>>>>>>> Then a UAC, on > >>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>>>>>> This would allow > >>>>>>>>> business as usual on this dialog (but without the benefit > >>>>>>>> of connected > >>>>>>>>> identity, therefore no worse than at present). It avoids > >>>>>>>> any change to RFC > >>>>>>>>> 4474, because verification is optional anyway. > >>>>>>>>> > >>>>>>>>> Would this work? > >>>>>>>>> > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 > >>>>>>>>>> To: Cullen Jennings; Jon Peterson > >>>>>>>>>> Cc: SIP; Paul Kyzivat > >>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: > >>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>> > >>>>>>>>>> Cullen, Jon, > >>>>>>>>>> > >>>>>>>>>> In case you missed this (it wasn't addressed > directly to you), > >>>>>>>>>> I would greatly appreciate an opinion from each of > you on this > >>>>>>>>>> remaining issue in connected-identity. Just to > summarise, RFC > >>>>>>>>>> 4474 leaves it up to policy whether to return a > 428 response > >>>>>>>>>> if Identity is missing, but mandates the sending > of a 436, 437 > >>>>>>>>>> or 438 response for certain errors arising while > verifying the > >>>>>>>>>> signature. It seems that for mid dialog requests this > >>>>>>>>>> behaviour could be harmful. What does the UAC for the mid > >>>>>>>>>> dialog request do if it receives 436, 437 or 438? If the > >>>>>>>>>> mid-dialog request was solely for the purpose of connected > >>>>>>>>>> identity, it can give up and allow the call to > continue as is. > >>>>>>>>>> But if the request was for some other purpose (e.g., > >>>>>>>>>> renegotiating the session because of hold, say, or session > >>>>>>>>>> timer refresh), the UAC really wants it to work. For the > >>>>>>>>>> normal case where the Authentication Service is at > a proxy, > >>>>>>>>>> not at the UAC, the UAC cannot force the Authentication > >>>>>>>>>> Service to refrain from putting this unverifiable > signature in > >>>>>>>>>> the mid-dialog request, so any attempts to repeat > the request > >>>>>>>>>> would most likely be doomed to getting the same response. > >>>>>>>>>> > >>>>>>>>>> It seems there are three things we could do, none very > >>>>>> attractive: > >>>>>>>>>> 1. Get connected-identity to modify the procedures > of RFC 4474 > >>>>>>>>>> for a verifier by softening the requirements for > sending 436, > >>>>>>>>>> 437 and 438 in response to mid-dialog requests. But then a > >>>>>>>>>> mid-dialog request from a rogue source would be accepted. > >>>>>>>>>> 2. Say that the Authentication Service should omit > the signing > >>>>>>>>>> of mid-dialog requests if a previous attempt has > resulted in > >>>>>>>>>> 436, 437 or 438. But this implies statefulness > >>>>>>>> at the AS. > >>>>>>>>>> 3. Accept the fact the mid-dialog requests can > fail in this > >>>>>>>>>> way and therefore things like session refresh and session > >>>>>>>>>> renegotiation cannot be done, probably resulting in call > >>>>>>>>>> failure. Sounds bad, but it is no different from > an initial > >>>>>>>>>> INVITE request, where there is nothing the UAC can > do if the > >>>>>>>>>> AS inserts an Identity header that gets rejected with 436, > >>>>>>>> 437 or 438. > >>>>>>>>>> John > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>>> September 2006 19:26 > >>>>>>>>>>> To: Elwell, John > >>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>>> > >>>>>>>>>>> John, > >>>>>>>>>>> > >>>>>>>>>>> I want to hear what others, especially Jon and > Cullen, have > >>>>>>>>>>> to say about this. > >>>>>>>>>>> > >>>>>>>>>>> It is of some concern to me that a call might fail > >>>>>>>> because of some > >>>>>>>>>>> problem with the identity mechanism when the same call > >>>>>> might have > >>>>>>>>>>> succeeded in the absence of any identity. > >>>>>>>>>>> > >>>>>>>>>>> But possibly the solution to this is policy in the > >>>>>>>>>>> implementation of the verifier. What to do in the > case of the > >>>>>>>>>>> conditions that > >>>>>>>>>> lead to these > >>>>>>>>>>> errors could be configurable in the verifier: either to > >>>>>>>>>> generate the > >>>>>>>>>>> error or simply to remove the identity info from the > >>>>>>>>>> message. And the > >>>>>>>>>>> policy could conceivably vary based on attributes of the > >>>>>>>>>>> message, such as whether it is in-dialog or not. > >>>>>>>>>>> > >>>>>>>>>>> Does it require a change to 4474 to permit that kind > >>>> of policy? > >>>>>>>>>>> It would be annoying if the end user had no > control over the > >>>>>>>>>>> insertion and verification of identity, and it > resulted in > >>>>>>>>>>> calls failing that the user would like to permit. But I > >>>>>>>>>>> suppose that is itself > >>>>>> a policy > >>>>>>>>>>> decision. There are certainly enterprises that > want to exert > >>>>>>>>>>> that kind of control over what users are permitted to do. > >>>>>>>>>>> > >>>>>>>>>>> Paul > >>>>>>>>>>> > >>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>> Paul, > >>>>>>>>>>>> > >>>>>>>>>>>> I agree with most of your points, and on > reflection I think > >>>>>>>>>>> I agree that the > >>>>>>>>>>>> solution has to be with the verifier. > >>>>>>>>>>>> > >>>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 > >>>>>>>>>>> 'Use Identity > >>>>>>>>>>>> Header' response is concerned, because that is left to > >>>>>>>>>>> policy, so we could > >>>>>>>>>>>> say in connected-identity that policy should be to not > >>>>>> send 428. > >>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>>>>>> because RFC 4474 says > >>>>>>>>>>>> that they MUST be sent under respective conditions. > >>>>>>>>>>> Interestingly, though, > >>>>>>>>>>>> there are other failure scenarios that can arise from the > >>>>>>>>>>> procedures of > >>>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is > >>>>>>>>>>> given on how to > >>>>>>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>>>>>> authoritative for the > >>>>>>>>>>>> domain. > >>>>>>>>>>>> > >>>>>>>>>>>> So one way to solve the present problem would be for the > >>>>>>>>>>> connected-identity > >>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 > in the case > >>>>>>>>>>> of mid-dialog > >>>>>>>>>>>> requests. I guess this would mean that it would > update RFC > >>>>>>>>>>> 4474 as well as > >>>>>>>>>>>> updating RFC 3261. But I don't like this, > because it seems > >>>>>>>>>>> to remove some of > >>>>>>>>>>>> the security properties of RFC 4474. > >>>>>>>>>>>> > >>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>>>>>> responses will be sent, > >>>>>>>>>>>> and failure to verify a signature will therefore > result in > >>>>>>>>>>> inability to > >>>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the > >>>>>>>>>> UPDATE or > >>>>>>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>>>>>> session timer refresh > >>>>>>>>>>>> or modifying the session, that action will fail. Then the > >>>>>>>>>>> call will fail (in > >>>>>>>>>>>> the case of inability to refresh the session timer) or > >>>>>>>> the session > >>>>>>>>>>>> modification will fail. I guess this is somewhat > analogous > >>>>>>>>>>> to caller ID > >>>>>>>>>>>> verification failure in an INVITE request - it is > >>>>>>>>>>> impossible to establish a > >>>>>>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>>>>>> ability to rectify the > >>>>>>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>>>>>> Authentication Service > >>>>>>>>>>>> that puts a rogue Identity header field in every request. > >>>>>>>>>>> In the connected > >>>>>>>>>>>> identity case, the only difference is that the call is > >>>>>>>>>>> already established > >>>>>>>>>>>> but is likely to fail if verification fails. > >>>>>>>>>>>> > >>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>>>>>> wrong source, then > >>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>>>>>>>> thing to do, and > >>>>>>>>>>>> overriding the verification procedures of RFC 4474 would > >>>>>>>>>>> indeed be the wrong > >>>>>>>>>>>> thing to do. So perhaps we just have to accept that these > >>>>>>>>>>> response codes can > >>>>>>>>>>>> be received and will lead to failure. > >>>>>>>>>>>> > >>>>>>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>>>>>> sending a 428 and > >>>>>>>>>>>> accept the consequences of other responses that the > >>>>>>>>>>> verifier might send. > >>>>>>>>>>>> John > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>>>>> September 2006 15:13 > >>>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>>>> From: Cullen Jennings > [mailto:fluffy@cisco.com] When an > >>>>>>>>>>>>>>> Update is sent. Are there any conditions > >>>>>> under which > >>>>>>>>>>>>>>> it might be rejected. Bad identity for > example. I think > >>>>>>>>>>>>>>> that > >>>>>>>>>>> might need a > >>>>>>>>>>>>>>> little discussion and also what the UA does > when it sends > >>>>>>>>>>>>> an update > >>>>>>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>>>>>> situation where it is > >>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>>>>>> purposes such as > >>>>>>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>>>>>> because connected > >>>>>>>>>>>>>> identity fails. > >>>>>>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a > mid-dialog request > >>>>>>>>>>>>> with 428 'Use > >>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>> I'm not sure about this. At the least I think this > >>>> one needs > >>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the > >>>>>>>>>>>>> conditions when > >>>>>>>>>>> it can be > >>>>>>>>>>>>> violated. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>>>>>> challenge on an > >>>>>>>>>>>>> in-dialog request. In some cases it is the right > >>>> thing to do. > >>>>>>>>>>>>> A UA that imposes such a requirement will be > >>>> limited in what > >>>>>>>>>>>>> it can do, but that may still be right in some cases. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>>>>>> Identity header field > >>>>>>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>>>>>> dialog has resulted in > >>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported > Certificate' or > >>>>>>>>>>>>> 438 'Invalid > >>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>> This requirement would force the authentication > service to > >>>>>>>>>>> be dialog > >>>>>>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>>>>>> back into the > >>>>>>>>>>>>> sender of the request. This may require a way > for the UAC > >>>>>>>>>>> to tell the > >>>>>>>>>>>>> authentication service not to act. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>>>>>>>>>>> results in one of > >>>>>>>>>>>>>> these responses if the mid-dialog request was > not solely > >>>>>>>>>>>>> for the purpose of > >>>>>>>>>>>>>> connected identity. If solely for the purpose > of connected > >>>>>>>>>>>>> identity there is > >>>>>>>>>>>>>> no point in repeating it, so I will say > "SHOULD NOT take > >>>>>>>>>>> any further > >>>>>>>>>>>>>> action". > >>>>>>>>>>>>> This seems wrong to me. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think that the remedy to these is in the > verifier. The > >>>>>>>>>>>>> purpose of the verifier is ultimately to drive an > >>>>>>>>>>>>> authorization > >>>> decision. If > >>>>>>>>>>>>> authorization would succeed in the absence of the > >>>>>>>>>>> identity, then the > >>>>>>>>>>>>> request should be permitted to continue as if > the identity > >>>>>>>>>>>>> was not present. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Unfortunately this would seem to require a > revision to 4474 > >>>>>>>>>>>>> even though the paint is hardly dry on it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> If this is done, then there is no need of a mechanism to > >>>>>>>>>> cause the > >>>>>>>>>>>>> authentication service *not* to authenticate. If this is > >>>>>>>>>>> *not* done, > >>>>>>>>>>>>> then that need remains, which will still require a > >>>>>>>>>> change to 4474. > >>>>>>>>>>>>> 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 > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 11 16:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXl5K-00057v-VQ; Wed, 11 Oct 2006 16:53:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXl5J-00057n-8n for sip@ietf.org; Wed, 11 Oct 2006 16:53:49 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXl5H-0007NN-TA for sip@ietf.org; Wed, 11 Oct 2006 16:53:49 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F00011E8C28; Wed, 11 Oct 2006 13:53:44 -0700 (PDT) To: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> From: Eric Rescorla Date: Wed, 11 Oct 2006 13:53:44 -0700 In-Reply-To: (Robert Sparks's message of "Wed, 11 Oct 2006 13:16:21 -0500") Message-ID: <86fyduh8vb.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: 4adaf050708fb13be3316a9eee889caa Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , 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 Robert Sparks writes: > So, I read this to say the proposed recommendation of CRC32 as > specified in rfc3309 is ok to go forward with. I think this is fine. > Based on the discussion, I think I will also point out that MD5 can > be used (and has been used in the past), > that its use would rely only on its collision properties, not any > cryptographic properties, and point out that it > is much slower than the alternative above. > > Any objection? No to the choice of CRC32, but yes to the language you suggest above. Collision-resistance is a technical term in cryptography, the text above is quite confusing. Informally, the property you want is that two hashes of the input values have a 2^(-b) chance of having the same hash value. Formalizing this turns out to be a really knotty problem especially if you assume (as is true in this case) that the input strings are non-uniform. (universal hashing is one way around this problem). Anyway, I think the correct language ought to be something like this: A common way to create the second part of the branch parameter value when forking a request is to compute a hash over the concatenation of the Request-URI, any Route header field values used during processing the request and any other values used by the location service logic while processing this request. The hash should be chosen so that there is a low probability that two distinct sets of these parameters will collide. Because the maximum number of messages which need to be compared is 70 [is this right], the chance of a collision is low even with a relatively small hash value, such as 32 bits. CRC-32 [REF] is a specific acceptable function, as is MD5 [REF]. Note that MD5 is being chosen purely for non-cryptographic properties. An attacker who can control the inputs in order to produce a hash collision can attack the connection in a variety of other ways. -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 Oct 11 17:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlHH-00054G-Ee; Wed, 11 Oct 2006 17:06:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlHG-00054B-F7 for sip@ietf.org; Wed, 11 Oct 2006 17:06:10 -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 1GXlHF-0000E3-1a for sip@ietf.org; Wed, 11 Oct 2006 17:06:10 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9BL5wRQ028362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Oct 2006 16:05:58 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <86fyduh8vb.fsf@raman.networkresonance.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> <86fyduh8vb.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56FAE1D8-843E-44EF-A3CB-B882393AB0AD@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Wed, 11 Oct 2006 16:05:57 -0500 To: EKR X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , 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 Thanks Ekr! inline. On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote: > Robert Sparks writes: > >> So, I read this to say the proposed recommendation of CRC32 as >> specified in rfc3309 is ok to go forward with. > > I think this is fine. > > >> Based on the discussion, I think I will also point out that MD5 can >> be used (and has been used in the past), >> that its use would rely only on its collision properties, not any >> cryptographic properties, and point out that it >> is much slower than the alternative above. >> >> Any objection? > > No to the choice of CRC32, but yes to the language you suggest > above. Collision-resistance is a technical term in cryptography, > the text above is quite confusing. I was being too sloppy - sorry. > > Informally, the property you want is that two hashes of the > input values have a 2^(-b) chance of having the same hash > value. Formalizing this turns out to be a really knotty problem > especially if you assume (as is true in this case) that the > input strings are non-uniform. (universal hashing is one > way around this problem). > > Anyway, I think the correct language ought to be something > like this: > > A common way to create the second part of the branch parameter > value when forking a request is to compute a hash over the > concatenation of the Request-URI, any Route header field values > used during processing the request and any other values used by the > location service logic while processing this request. The hash > should be chosen so that there is a low probability that two > distinct sets of these parameters will collide. Because the maximum > number of messages which need to be compared is 70 [is this right], yes, but I'll replace messages with a phrase that says "via branch parameters in a given message" but with better wordsmithing. > the chance of a collision is low even with a relatively small hash > value, such as 32 bits. CRC-32 [REF] is a specific acceptable > function, as is MD5 [REF]. Note that MD5 is being chosen purely > for non-cryptographic properties. An attacker who can control the > inputs in order to produce a hash collision can attack the > connection in a variety of other ways. _Thank you_ for the text! RjS > > -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 Oct 11 17:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlQs-0005oA-0k; Wed, 11 Oct 2006 17:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlQq-0005eG-CJ for sip@ietf.org; Wed, 11 Oct 2006 17:16:04 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXlQp-000141-0G for sip@ietf.org; Wed, 11 Oct 2006 17:16:04 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7C6A11E8C28; Wed, 11 Oct 2006 14:16:02 -0700 (PDT) To: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> <86fyduh8vb.fsf@raman.networkresonance.com> <56FAE1D8-843E-44EF-A3CB-B882393AB0AD@estacado.net> From: Eric Rescorla Date: Wed, 11 Oct 2006 14:16:02 -0700 In-Reply-To: <56FAE1D8-843E-44EF-A3CB-B882393AB0AD@estacado.net> (Robert Sparks's message of "Wed, 11 Oct 2006 16:05:57 -0500") Message-ID: <86ac42h7u5.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: 7aafa0432175920a4b3e118e16c5cb64 Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , 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 Robert Sparks writes: > Thanks Ekr! > > inline. > > On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote: > >> Robert Sparks writes: >> >>> So, I read this to say the proposed recommendation of CRC32 as >>> specified in rfc3309 is ok to go forward with. >> >> I think this is fine. >> >> >>> Based on the discussion, I think I will also point out that MD5 can >>> be used (and has been used in the past), >>> that its use would rely only on its collision properties, not any >>> cryptographic properties, and point out that it >>> is much slower than the alternative above. >>> >>> Any objection? >> >> No to the choice of CRC32, but yes to the language you suggest >> above. Collision-resistance is a technical term in cryptography, >> the text above is quite confusing. > I was being too sloppy - sorry. > >> >> Informally, the property you want is that two hashes of the >> input values have a 2^(-b) chance of having the same hash >> value. Formalizing this turns out to be a really knotty problem >> especially if you assume (as is true in this case) that the >> input strings are non-uniform. (universal hashing is one >> way around this problem). >> >> Anyway, I think the correct language ought to be something >> like this: >> >> A common way to create the second part of the branch parameter >> value when forking a request is to compute a hash over the >> concatenation of the Request-URI, any Route header field values >> used during processing the request and any other values used by the >> location service logic while processing this request. The hash >> should be chosen so that there is a low probability that two >> distinct sets of these parameters will collide. Because the maximum >> number of messages which need to be compared is 70 [is this right], > yes, but I'll replace messages with a phrase that says > "via branch parameters in a given message" but with better wordsmithing. Right. I actually meant "inputs" :) -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 Oct 11 18:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXmLS-0003ti-Rx; Wed, 11 Oct 2006 18:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXmLR-0003tM-Tm for sip@ietf.org; Wed, 11 Oct 2006 18:14:33 -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 1GXmLQ-0006g7-J4 for sip@ietf.org; Wed, 11 Oct 2006 18:14:33 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Oct 2006 15:14:32 -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 k9BMEWXu001270; Wed, 11 Oct 2006 15:14:32 -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 k9BMEVAo026767; Wed, 11 Oct 2006 15:14:31 -0700 (PDT) Received: from [171.71.97.102] (dhcp-171-71-97-102.cisco.com [171.71.97.102]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9BM2usU027443; Wed, 11 Oct 2006 15:02:56 -0700 Message-ID: <452D6CD6.4070402@cisco.com> Date: Wed, 11 Oct 2006 15:14:46 -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: EKR Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> <86fyduh8vb.fsf@raman.networkresonance.com> In-Reply-To: <86fyduh8vb.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; 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=2469; t=1160604872; x=1161468872; 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:Re=3A=20[Sip]=20Good=20Hash=3A=20draft-ietf-sip-fork-loop-fix-03; X=v=3Dcisco.com=3B=20h=3DVcADUG4YAjhJCOUESy9WKP9y43s=3D; b=wO9Byu86Wp5SfzSSPf8XOqzFeMukScLFRvq1EG+YYgE4nqm1pVXikzdXCKDRA7xWcBX97VIa fVbmmu2CjMTUKYaGgGjL7Igh/bXU9we/ZTejmwjN6/ieUMbIzteyoIVA; X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Cullen Jennings , SIP , Pete Cordell , Robert Sparks , 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 Is it just me, or do others think that this warrents a SHOULD level set of choices? The cost of a collision is probably some pretty weird behavior, and given no real constraint we can be pretty well assured that somebody will use the lack of normative language to do the wrong thing. Or am I being all too net-nannyish? Mike Eric Rescorla wrote: >Robert Sparks writes: > > > >>So, I read this to say the proposed recommendation of CRC32 as >>specified in rfc3309 is ok to go forward with. >> >> > >I think this is fine. > > > > >>Based on the discussion, I think I will also point out that MD5 can >>be used (and has been used in the past), >>that its use would rely only on its collision properties, not any >>cryptographic properties, and point out that it >>is much slower than the alternative above. >> >>Any objection? >> >> > >No to the choice of CRC32, but yes to the language you suggest >above. Collision-resistance is a technical term in cryptography, >the text above is quite confusing. > >Informally, the property you want is that two hashes of the >input values have a 2^(-b) chance of having the same hash >value. Formalizing this turns out to be a really knotty problem >especially if you assume (as is true in this case) that the >input strings are non-uniform. (universal hashing is one >way around this problem). > >Anyway, I think the correct language ought to be something >like this: > > A common way to create the second part of the branch parameter > value when forking a request is to compute a hash over the > concatenation of the Request-URI, any Route header field values > used during processing the request and any other values used by the > location service logic while processing this request. The hash > should be chosen so that there is a low probability that two > distinct sets of these parameters will collide. Because the maximum > number of messages which need to be compared is 70 [is this right], > the chance of a collision is low even with a relatively small hash > value, such as 32 bits. CRC-32 [REF] is a specific acceptable > function, as is MD5 [REF]. Note that MD5 is being chosen purely > for non-cryptographic properties. An attacker who can control the > inputs in order to produce a hash collision can attack the > connection in a variety of other ways. > >-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 Thu Oct 12 00:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrvU-0001tk-SO; Thu, 12 Oct 2006 00:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrvT-0001tX-So for sip@ietf.org; Thu, 12 Oct 2006 00:12:07 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXrvQ-0006M4-Hd for sip@ietf.org; Thu, 12 Oct 2006 00:12:07 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 8DD27205FE for ; Thu, 12 Oct 2006 09:37:09 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 76280205F3 for ; Thu, 12 Oct 2006 09:37:09 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 09:42:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Changing SSRC/sequence numbers during a call Date: Thu, 12 Oct 2006 09:42:01 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB00BF@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Changing SSRC/sequence numbers during a call Thread-Index: AcbtT0StiHn+TzhES4S8s5Y5G+np0AAZUPlA From: To: , X-OriginalArrivalTime: 12 Oct 2006 04:12:02.0327 (UTC) FILETIME=[91D63A70:01C6EDB4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f 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="===============0595249485==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0595249485== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EDB4.912AD99A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EDB4.912AD99A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 SSRC is used per session as an identifier of the source. It will not be changed in a Session. In a session, if there is a collision with the SSRC from the other side it should be changed (This is a very rare case!!) =20 Ina video call, where you have audio and video for each medium a SSRC is used. So what type of call are you making? Is it a multimedia call? =20 Questions related to RTP can be posted @ rtp@vovida.org =20 HTH, Sreeram. =20 =20 ________________________________ From: Dhodapkar Chinmay-C23627 [mailto:chinmay.dhodapkar@motorola.com]=20 Sent: Wednesday, October 11, 2006 9:37 PM To: sip@ietf.org Subject: [Sip] Changing SSRC/sequence numbers during a call =20 Hi, =20 Can the SSRC of RTP packets change midway between the call. The scenario is that the call has been set up using the usual SIP/SDP signalling. After this there is no further signalling between the two entities, but the SSRC changes. Is this valid? Since nothing else changed (remote ip/port,=20 remote entity, there is no conflict of SSRCs, etc). =20 Looking forward to some inputs on this. Regards, Chinmay Dhodapkar =20 ------_=_NextPart_001_01C6EDB4.912AD99A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

SSRC is used per session as an = identifier of the source. It will not be changed in a = Session.

In a session, if there is a = collision with the SSRC from the other side it should be changed (This is a very rare = case!!)

 

Ina video call, where you have = audio and video for each medium a SSRC is used.

So what type of call are you = making? Is it a multimedia call?

 

Questions related to RTP can be = posted @ rtp@vovida.org

 

HTH,

Sreeram.

 

 

From: = Dhodapkar Chinmay-C23627 [mailto:chinmay.dhodapkar@motorola.com]
Sent: Wednesday, October = 11, 2006 9:37 PM
To: sip@ietf.org
Subject: [Sip] Changing SSRC/sequence numbers during a call

 

Hi,

 

Can the SSRC of RTP packets change midway between the = call. The scenario is that the call has been set up using the usual = SIP/SDP signalling.

After this there is no further signalling between the = two entities, but the SSRC changes. Is this valid? Since nothing else = changed (remote ip/port,

remote entity, there is no conflict of SSRCs, = etc).

 

Looking forward to some inputs on = this.

Regards,

Chinmay Dhodapkar

 

------_=_NextPart_001_01C6EDB4.912AD99A-- --===============0595249485== 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 --===============0595249485==-- From sip-bounces@ietf.org Thu Oct 12 01:59:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtYF-0002hN-3v; Thu, 12 Oct 2006 01:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXtYC-0002gz-2A; Thu, 12 Oct 2006 01:56:12 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXtY7-0002th-5T; Thu, 12 Oct 2006 01:56:12 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id D7143205FA; Thu, 12 Oct 2006 11:21:05 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id C4AF4205F2; Thu, 12 Oct 2006 11:21:05 +0530 (IST) Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 11:25:58 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by HYD-MDP-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 11:25:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 11:28:51 +0530 Message-ID: <94350539FC77154CBBF37A9B9284133D015F98E2@HYD-MKD-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP IM Client Thread-Index: Acbtw33cKA94YpKsSLqbCyc1NtgrmA== From: To: , X-OriginalArrivalTime: 12 Oct 2006 05:55:51.0784 (UTC) FILETIME=[12E1EE80:01C6EDC3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Sip] SIP IM Client X-BeenThere: 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="===============1080890115==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1080890115== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EDC3.42E8C216" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EDC3.42E8C216 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi There Can any one suggest me the IM client open source which built on SIP protocol. An early response in this regard is appreciated. =20 Regards Kamal ------_=_NextPart_001_01C6EDC3.42E8C216 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 There
Can any=20 one suggest me the IM client  open source which built on SIP=20 protocol.
An = early response in=20 this regard is appreciated.
 
Regards
Kamal
------_=_NextPart_001_01C6EDC3.42E8C216-- --===============1080890115== 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 --===============1080890115==-- From sip-bounces@ietf.org Thu Oct 12 04:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvU2-0004rl-Gz; Thu, 12 Oct 2006 04:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvU1-0004rg-Ip for sip@ietf.org; Thu, 12 Oct 2006 04:00:01 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvU0-0008Ry-A2 for sip@ietf.org; Thu, 12 Oct 2006 04:00:01 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62448 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1GXvTz-0004yL-69; Thu, 12 Oct 2006 08:59:59 +0100 In-Reply-To: <8A24F115EA58164490CD026E9D0CEAD4AB00BF@BLR-EC-MBX02.wipro.com> References: <8A24F115EA58164490CD026E9D0CEAD4AB00BF@BLR-EC-MBX02.wipro.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30E0E7F3-A3C4-405D-88C1-3BBB00C2FB68@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [Sip] Changing SSRC/sequence numbers during a call Date: Thu, 12 Oct 2006 08:59:55 +0100 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, chinmay.dhodapkar@motorola.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 12 Oct 2006, at 05:12, wrote: > SSRC is used per session as an identifier of the source. It will > not be changed in a Session. The SSRC of a participant can change within a session if there is a collision (as noted below), or if the participant generates multiple streams within the session. For example, if a participant has two cameras and switches between then, the video from each camera should use a different SSRC [RFC 3550 section 3]. > In a session, if there is a collision with the SSRC from the other > side it should be changed (This is a very rare case!!) > > > > Ina video call, where you have audio and video for each medium a > SSRC is used. > > So what type of call are you making? Is it a multimedia call? > > > > Questions related to RTP can be posted @ rtp@vovida.org Or to the IETF AVT working group which designed RTP. Colin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 04:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvej-0003OT-6B; Thu, 12 Oct 2006 04:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXveh-0003OO-LI for sip@ietf.org; Thu, 12 Oct 2006 04:11:03 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvef-0003GN-PZ for sip@ietf.org; Thu, 12 Oct 2006 04:11:03 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 66CE3206B4 for ; Thu, 12 Oct 2006 13:36:02 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 4CAAA206A0 for ; Thu, 12 Oct 2006 13:36:02 +0530 (IST) Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 13:40:55 +0530 Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by HYD-MDP-MBX01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 13:40:52 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Oct 2006 13:43:45 +0530 Message-ID: <94350539FC77154CBBF37A9B9284133D015F99EE@HYD-MKD-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP IM Client Thread-Index: Acbt1lYfyIjRPJ2zSLiPcHg96tuSlg== From: To: X-OriginalArrivalTime: 12 Oct 2006 08:10:52.0142 (UTC) FILETIME=[EF1278E0:01C6EDD5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] SIP IM Client X-BeenThere: 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="===============1670834282==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1670834282== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6EDD6.1AF48BBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6EDD6.1AF48BBA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi There Can any one suggest me the IM client open source which built on SIP protocol. An early response in this regard is appreciated. =20 Regards Kamal =20 ------_=_NextPart_001_01C6EDD6.1AF48BBA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 There
Can any=20 one suggest me the IM client  open source = which built=20 on SIP protocol.
An = early response in=20 this regard is appreciated.
 
Regards
Kamal
 
------_=_NextPart_001_01C6EDD6.1AF48BBA-- --===============1670834282== 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 --===============1670834282==-- From sip-bounces@ietf.org Thu Oct 12 06:36:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxrp-0000UK-39; Thu, 12 Oct 2006 06:32:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxrn-0000UF-PD for sip@ietf.org; Thu, 12 Oct 2006 06:32:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxrh-0002KU-AN for sip@ietf.org; Thu, 12 Oct 2006 06:32:43 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 82F11F60; Thu, 12 Oct 2006 12:32:34 +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, 12 Oct 2006 12:32:34 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 12:32:33 +0200 Received: from [131.160.36.27] (EH3I2003TGFCPET-131160036027.lmf.ericsson.se [131.160.36.27]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B037A251E; Thu, 12 Oct 2006 13:32:33 +0300 (EEST) Message-ID: <452E19C1.1030406@ericsson.com> Date: Thu, 12 Oct 2006 13:32:33 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: sip References: <026F8EEDAD2C4342A993203088C1FC05038FDD03@esealmw109.eemea.ericsson.se> <45262C71.8090003@ericsson.com> <452E189E.9050800@ericsson.com> In-Reply-To: <452E189E.9050800@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2006 10:32:33.0515 (UTC) FILETIME=[BA490BB0:01C6EDE9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: zhigang.c.liu@nokia.com, Adam Roach , "Surtees, Abigail" , Dean Willis , "West, Mark" , "Lars-Erik Jonsson \(LU/EAB\)" , richard.price@cogent-dsn.com, Carsten Bormann , Keith Drage Subject: [Sip] Request for review of draft-ietf-rohc-sigcomp-sip-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 Folks, we have just submitted the following draft, which defines how to use SigComp with SIP. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-03.txt We would like to ask the SIP WG to review this draft; especially Sections 6 through 10. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 14:41:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5Pf-00038Q-HL; Thu, 12 Oct 2006 14:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5Pe-00038K-6j for sip@ietf.org; Thu, 12 Oct 2006 14:36:10 -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 1GY5Pb-0000rL-SA for sip@ietf.org; Thu, 12 Oct 2006 14:36:10 -0400 Received: from [172.17.2.252] ([172.17.2.252]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9CIa3SG066720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Oct 2006 13:36:04 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <452D6CD6.4070402@cisco.com> References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> <86fyduh8vb.fsf@raman.networkresonance.com> <452D6CD6.4070402@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: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Thu, 12 Oct 2006 13:36:02 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Cullen Jennings , SIP , Pete Cordell , 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 There's been a lot of pushback in the past about any normative strength in this recommendation. On Oct 11, 2006, at 5:14 PM, Michael Thomas wrote: > Is it just me, or do others think that this warrents a SHOULD level > set of choices? > The cost of a collision is probably some pretty weird behavior, and > given no real > constraint we can be pretty well assured that somebody will use the > lack of normative > language to do the wrong thing. Or am I being all too net-nannyish? > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 15:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6Ol-00072f-R4; Thu, 12 Oct 2006 15:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6Ok-000722-Cd for sip@ietf.org; Thu, 12 Oct 2006 15:39:18 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY6FD-00034V-H0 for sip@ietf.org; Thu, 12 Oct 2006 15:29:29 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20061012192925m1100rsv5ee>; Thu, 12 Oct 2006 19:29:25 +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 k9CJTOUm027847 for ; Thu, 12 Oct 2006 15:29:24 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k9CJTOJ4027843; Thu, 12 Oct 2006 15:29:24 -0400 Date: Thu, 12 Oct 2006 15:29:24 -0400 Message-Id: <200610121929.k9CJTOJ4027843@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (rjsparks@estacado.net) Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 References: <0J5L00L28GI2JL40@jes-fe2.zx.nl> <9102F009-D9C4-4C18-8670-C95F2E98867E@cisco.com> <4522AA1F.4040604@softarmor.com> <683BA38E-E7D4-436C-B964-9B9D6775B827@estacado.net> <99BBB4C6-14B7-40FE-BE90-02899428A540@cisco.com> <1207432B-5F09-4B2E-B14A-CC2CCC628878@estacado.net> <4523FEEF.1080501@cisco.com> <61797775-A54C-4947-9F69-9C18D69947CC@cisco.com> <45248E06.305@cisco.com> <86fyduh8vb.fsf@raman.networkresonance.com> <452D6CD6.4070402@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 On Oct 11, 2006, at 5:14 PM, Michael Thomas wrote: > Is it just me, or do others think that this warrents a SHOULD > level set of choices? The cost of a collision is probably some > pretty weird behavior, and given no real constraint we can be > pretty well assured that somebody will use the lack of normative > language to do the wrong thing. Or am I being all too > net-nannyish? There's been a lot of pushback in the past about any normative strength in this recommendation. Someone pointed out that since the call-ID and/or branch parameter (I forget which) is included in the hash, if a call fails due to a hash collision, a retry of the call will fail (or rather, it will fail independently, which is unlikely). So the penalty for a deficient hash function is small. 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 Oct 12 18:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96I-000691-P5; Thu, 12 Oct 2006 18:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96H-00064k-72 for sip@ietf.org; Thu, 12 Oct 2006 18:32:25 -0400 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY96F-00015w-VY for sip@ietf.org; Thu, 12 Oct 2006 18:32:25 -0400 Received: from ATL1VEXC008.usdom003.tco.tc ([10.158.7.26]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Oct 2006 18:31:42 -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 Date: Thu, 12 Oct 2006 18:30:08 -0400 Message-ID: <77BD870EA838FC469FDD2AE248B1357B01217690@ATL1VEXC008.usdom003.tco.tc> In-Reply-To: <9AA10AB73EBF3A45ADB921873D8BE953021CE833@xmb-sjc-218.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] RFC3263 - Server Usage query Thread-Index: AcbtSr9kKtMXcUnhT7ypmrBVcKHFpAA+7Hwg From: "Brett Tate" To: "Sachin Danait \(sdanait\)" , X-OriginalArrivalTime: 12 Oct 2006 22:31:42.0372 (UTC) FILETIME=[31021E40:01C6EE4E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org Subject: [Sip] RE: [Sip-implementors] RFC3263 - Server Usage query X-BeenThere: sip@ietf.org X-Mailman-Version: 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 question is regarding the first step of the above response=20 > processing logic.=20 >=20 > =20 >=20 > Since SRV lookups are performed on a domain-name only when no=20 > port is specified, this obligates the sender of a request to=20 > not encode a port in its Via header if that sender wishes to=20 > be reachable using SRV resolution. Consequently, this appears=20 > to imply that the sender needs to be listening for responses=20 > on the default SIP port in addition to any of the ports=20 > resolved from the SRV query, since the first transmission of=20 > any incoming response will always be directed towards the=20 > default port as per section 18.2.2 of RFC3261. =20 Yes, when sending over a non reliable transport. =20 =20 > As I understand it, based on how this rule is currently=20 > worded, if none of the SRV resolutions of Via Sent-By=20 > domain-name resolve to port 5060 AND if a UAC is not=20 > listening for responses on port 5060, the initial=20 > transmission of every response will always encounter a=20 > failure before resorting to SRV procedures. Yes. If the sender does not include a port and does not listen on 5060, the response will fail to be delivered over the non reliable transport. And if the sender of the response is unable to obtain knowledge of the failure (ICMP errors suppressed), the rfc3263 procedures will not occur. If UAS is able to detect the failure, the rfc3263 procedures should occur. The rfc3261 text (and limitation) appears intentional. However a SIP extension similar to rfc3581 could created and used. The maddr usage has a similar limitation; thus it would not help bypass the limitation. http://www1.ietf.org/mail-archive/web/sip/current/msg07554.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 12 23:52:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE30-00027h-97; Thu, 12 Oct 2006 23:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE2y-00027c-5B for sip@ietf.org; Thu, 12 Oct 2006 23:49:20 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYE2v-0007yQ-7T for sip@ietf.org; Thu, 12 Oct 2006 23:49:20 -0400 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Oct 2006 09:19:10 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id <4V45R16D>; Fri, 13 Oct 2006 09:19:10 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC041F6FE7@sindhu.ctd.hcltech.com> From: "Tom Jose - TLS , Chennai" Content-Transfer-Encoding: quoted-printable To: Date: Fri, 13 Oct 2006 09:19:09 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Oct 2006 03:49:10.0833 (UTC) FILETIME=[8AC69A10:01C6EE7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Subject: [Sip] RE: Changing SSRC/sequence numbers during a call X-BeenThere: sip@ietf.org X-Mailman-Version: 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: sip-request@ietf.org [mailto:sip-request@ietf.org]=20 Sent: Thursday, October 12, 2006 9:30 PM To: sip@ietf.org Subject: Sip Digest, Vol 30, Issue 26 Send Sip mailing list submissions to sip@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/sip or, via email, send a message with subject or body 'help' to sip-request@ietf.org You can reach the person managing the list at sip-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sip digest..." Today's Topics: 1. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Eric Rescorla) 2. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Robert Sparks) 3. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Eric Rescorla) 4. Re: Good Hash: draft-ietf-sip-fork-loop-fix-03 (Michael Thomas) 5. RE: Changing SSRC/sequence numbers during a call (sreeram.kanumuri@wipro.com) 6. SIP IM Client (kamalakar.mergu@wipro.com) 7. Re: Changing SSRC/sequence numbers during a call (Colin Perkins) 8. SIP IM Client (kamalakar.mergu@wipro.com) 9. Request for review of draft-ietf-rohc-sigcomp-sip-03.txt (Gonzalo Camarillo) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Oct 2006 13:53:44 -0700 From: Eric Rescorla Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 To: Robert Sparks Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , Dean Willis Message-ID: <86fyduh8vb.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=3Dus-ascii Robert Sparks writes: > So, I read this to say the proposed recommendation of CRC32 as > specified in rfc3309 is ok to go forward with. I think this is fine. > Based on the discussion, I think I will also point out that MD5 can > be used (and has been used in the past), > that its use would rely only on its collision properties, not any > cryptographic properties, and point out that it > is much slower than the alternative above. > > Any objection? No to the choice of CRC32, but yes to the language you suggest above. Collision-resistance is a technical term in cryptography, the text above is quite confusing.=20 Informally, the property you want is that two hashes of the input values have a 2^(-b) chance of having the same hash value. Formalizing this turns out to be a really knotty problem especially if you assume (as is true in this case) that the input strings are non-uniform. (universal hashing is one=20 way around this problem). Anyway, I think the correct language ought to be something like this: A common way to create the second part of the branch parameter value when forking a request is to compute a hash over the concatenation of the Request-URI, any Route header field values used during processing the request and any other values used by the location service logic while processing this request. The hash should be chosen so that there is a low probability that two distinct sets of these parameters will collide. Because the maximum number of messages which need to be compared is 70 [is this right], the chance of a collision is low even with a relatively small hash value, such as 32 bits. CRC-32 [REF] is a specific acceptable function, as is MD5 [REF]. Note that MD5 is being chosen purely for non-cryptographic properties. An attacker who can control the inputs in order to produce a hash collision can attack the connection in a variety of other ways. -Ekr ------------------------------ Message: 2 Date: Wed, 11 Oct 2006 16:05:57 -0500 From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 To: EKR Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , Dean Willis Message-ID: <56FAE1D8-843E-44EF-A3CB-B882393AB0AD@estacado.net> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed Thanks Ekr! inline. On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote: > Robert Sparks writes: > >> So, I read this to say the proposed recommendation of CRC32 as >> specified in rfc3309 is ok to go forward with. > > I think this is fine. > > >> Based on the discussion, I think I will also point out that MD5 can >> be used (and has been used in the past), >> that its use would rely only on its collision properties, not any >> cryptographic properties, and point out that it >> is much slower than the alternative above. >> >> Any objection? > > No to the choice of CRC32, but yes to the language you suggest > above. Collision-resistance is a technical term in cryptography, > the text above is quite confusing. I was being too sloppy - sorry. > > Informally, the property you want is that two hashes of the > input values have a 2^(-b) chance of having the same hash > value. Formalizing this turns out to be a really knotty problem > especially if you assume (as is true in this case) that the > input strings are non-uniform. (universal hashing is one > way around this problem). > > Anyway, I think the correct language ought to be something > like this: > > A common way to create the second part of the branch parameter > value when forking a request is to compute a hash over the > concatenation of the Request-URI, any Route header field values > used during processing the request and any other values used by the > location service logic while processing this request. The hash > should be chosen so that there is a low probability that two > distinct sets of these parameters will collide. Because the maximum > number of messages which need to be compared is 70 [is this right], yes, but I'll replace messages with a phrase that says "via branch parameters in a given message" but with better wordsmithing. > the chance of a collision is low even with a relatively small hash > value, such as 32 bits. CRC-32 [REF] is a specific acceptable > function, as is MD5 [REF]. Note that MD5 is being chosen purely > for non-cryptographic properties. An attacker who can control the > inputs in order to produce a hash collision can attack the > connection in a variety of other ways. _Thank you_ for the text! RjS > > -Ekr ------------------------------ Message: 3 Date: Wed, 11 Oct 2006 14:16:02 -0700 From: Eric Rescorla Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 To: Robert Sparks Cc: Cullen Jennings , SIP , Michael Thomas , Pete Cordell , Dean Willis Message-ID: <86ac42h7u5.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=3Dus-ascii Robert Sparks writes: > Thanks Ekr! > > inline. > > On Oct 11, 2006, at 3:53 PM, Eric Rescorla wrote: > >> Robert Sparks writes: >> >>> So, I read this to say the proposed recommendation of CRC32 as >>> specified in rfc3309 is ok to go forward with. >> >> I think this is fine. >> >> >>> Based on the discussion, I think I will also point out that MD5 can >>> be used (and has been used in the past), >>> that its use would rely only on its collision properties, not any >>> cryptographic properties, and point out that it >>> is much slower than the alternative above. >>> >>> Any objection? >> >> No to the choice of CRC32, but yes to the language you suggest >> above. Collision-resistance is a technical term in cryptography, >> the text above is quite confusing. > I was being too sloppy - sorry. > >> >> Informally, the property you want is that two hashes of the >> input values have a 2^(-b) chance of having the same hash >> value. Formalizing this turns out to be a really knotty problem >> especially if you assume (as is true in this case) that the >> input strings are non-uniform. (universal hashing is one >> way around this problem). >> >> Anyway, I think the correct language ought to be something >> like this: >> >> A common way to create the second part of the branch parameter >> value when forking a request is to compute a hash over the >> concatenation of the Request-URI, any Route header field values >> used during processing the request and any other values used by = the >> location service logic while processing this request. The hash >> should be chosen so that there is a low probability that two >> distinct sets of these parameters will collide. Because the = maximum >> number of messages which need to be compared is 70 [is this = right], > yes, but I'll replace messages with a phrase that says > "via branch parameters in a given message" but with better = wordsmithing. Right. I actually meant "inputs" :) -Ekr ------------------------------ Message: 4 Date: Wed, 11 Oct 2006 15:14:46 -0700 From: Michael Thomas Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 To: EKR Cc: Cullen Jennings , SIP , Pete Cordell , Robert Sparks , Dean Willis Message-ID: <452D6CD6.4070402@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Is it just me, or do others think that this warrents a SHOULD level set=20 of choices? The cost of a collision is probably some pretty weird behavior, and=20 given no real constraint we can be pretty well assured that somebody will use the lack = of normative language to do the wrong thing. Or am I being all too net-nannyish? Mike Eric Rescorla wrote: >Robert Sparks writes: > > =20 > >>So, I read this to say the proposed recommendation of CRC32 as >>specified in rfc3309 is ok to go forward with. >> =20 >> > >I think this is fine. > > > =20 > >>Based on the discussion, I think I will also point out that MD5 can >>be used (and has been used in the past), >>that its use would rely only on its collision properties, not any >>cryptographic properties, and point out that it >>is much slower than the alternative above. >> >>Any objection? >> =20 >> > >No to the choice of CRC32, but yes to the language you suggest >above. Collision-resistance is a technical term in cryptography, >the text above is quite confusing.=20 > >Informally, the property you want is that two hashes of the >input values have a 2^(-b) chance of having the same hash >value. Formalizing this turns out to be a really knotty problem >especially if you assume (as is true in this case) that the >input strings are non-uniform. (universal hashing is one=20 >way around this problem). > >Anyway, I think the correct language ought to be something >like this: > > A common way to create the second part of the branch parameter > value when forking a request is to compute a hash over the > concatenation of the Request-URI, any Route header field values > used during processing the request and any other values used by the > location service logic while processing this request. The hash > should be chosen so that there is a low probability that two > distinct sets of these parameters will collide. Because the maximum > number of messages which need to be compared is 70 [is this right], > the chance of a collision is low even with a relatively small hash > value, such as 32 bits. CRC-32 [REF] is a specific acceptable > function, as is MD5 [REF]. Note that MD5 is being chosen purely > for non-cryptographic properties. An attacker who can control the > inputs in order to produce a hash collision can attack the > connection in a variety of other ways. > >-Ekr > =20 > ------------------------------ Message: 5 Date: Thu, 12 Oct 2006 09:42:01 +0530 From: Subject: RE: [Sip] Changing SSRC/sequence numbers during a call To: , Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB00BF@BLR-EC-MBX02.wipro.com> Content-Type: text/plain; charset=3D"us-ascii" Hi, =20 SSRC is used per session as an identifier of the source. It will not be changed in a Session. In a session, if there is a collision with the SSRC from the other side it should be changed (This is a very rare case!!) =20 Ina video call, where you have audio and video for each medium a SSRC is used. So what type of call are you making? Is it a multimedia call? =20 Questions related to RTP can be posted @ rtp@vovida.org =20 HTH, Sreeram. =20 =20 ________________________________ From: Dhodapkar Chinmay-C23627 [mailto:chinmay.dhodapkar@motorola.com]=20 Sent: Wednesday, October 11, 2006 9:37 PM To: sip@ietf.org Subject: [Sip] Changing SSRC/sequence numbers during a call =20 Hi, =20 Can the SSRC of RTP packets change midway between the call. The scenario is that the call has been set up using the usual SIP/SDP signalling. After this there is no further signalling between the two entities, but the SSRC changes. Is this valid? Since nothing else changed (remote ip/port,=20 remote entity, there is no conflict of SSRCs, etc). =20 Looking forward to some inputs on this. Regards, Chinmay Dhodapkar =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/sip/attachments/20061012/51e990d9/attachme= nt. html ------------------------------ Message: 6 Date: Thu, 12 Oct 2006 11:28:51 +0530 From: Subject: [Sip] SIP IM Client To: , Message-ID: <94350539FC77154CBBF37A9B9284133D015F98E2@HYD-MKD-MBX01.wipro.com> Content-Type: text/plain; charset=3D"us-ascii" Hi There Can any one suggest me the IM client open source which built on SIP protocol. An early response in this regard is appreciated. =20 Regards Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/sip/attachments/20061012/b259a4f6/attachme= nt. html ------------------------------ Message: 7 Date: Thu, 12 Oct 2006 08:59:55 +0100 From: Colin Perkins Subject: Re: [Sip] Changing SSRC/sequence numbers during a call To: Cc: sip@ietf.org, chinmay.dhodapkar@motorola.com Message-ID: <30E0E7F3-A3C4-405D-88C1-3BBB00C2FB68@csperkins.org> Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; = format=3Dflowed On 12 Oct 2006, at 05:12, wrote: > SSRC is used per session as an identifier of the source. It will =20 > not be changed in a Session. The SSRC of a participant can change within a session if there is a =20 collision (as noted below), or if the participant generates multiple =20 streams within the session. For example, if a participant has two =20 cameras and switches between then, the video from each camera should =20 use a different SSRC [RFC 3550 section 3]. > In a session, if there is a collision with the SSRC from the other =20 > side it should be changed (This is a very rare case!!) > > > > Ina video call, where you have audio and video for each medium a =20 > SSRC is used. > > So what type of call are you making? Is it a multimedia call? > > > > Questions related to RTP can be posted @ rtp@vovida.org Or to the IETF AVT working group which designed RTP. Colin ------------------------------ Message: 8 Date: Thu, 12 Oct 2006 13:43:45 +0530 From: Subject: [Sip] SIP IM Client To: Message-ID: <94350539FC77154CBBF37A9B9284133D015F99EE@HYD-MKD-MBX01.wipro.com> Content-Type: text/plain; charset=3D"us-ascii" Hi There Can any one suggest me the IM client open source which built on SIP protocol. An early response in this regard is appreciated. =20 Regards Kamal =20 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/sip/attachments/20061012/9c1c8b1a/attachme= nt. html ------------------------------ Message: 9 Date: Thu, 12 Oct 2006 13:32:33 +0300 From: Gonzalo Camarillo Subject: [Sip] Request for review of draft-ietf-rohc-sigcomp-sip-03.txt To: sip Cc: zhigang.c.liu@nokia.com, Adam Roach , "Surtees, Abigail" , Dean Willis , "West, Mark" , "Lars-Erik Jonsson \(LU/EAB\)" , richard.price@cogent-dsn.com, Carsten Bormann , Keith Drage Message-ID: <452E19C1.1030406@ericsson.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Folks, we have just submitted the following draft, which defines how to use SigComp with SIP. Until it appears in the archives, you can fetch it = from: http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-03.txt We would like to ask the SIP WG to review this draft; especially Sections 6 through 10. Thanks, Gonzalo ------------------------------ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip End of Sip Digest, Vol 30, Issue 26 *********************************** DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 13 09:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNTZ-0002op-5Z; Fri, 13 Oct 2006 09:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNTW-0002lQ-S2 for sip@ietf.org; Fri, 13 Oct 2006 09:53:22 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYNTQ-0005ZH-Fm for sip@ietf.org; Fri, 13 Oct 2006 09:53:22 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.6/IER-o) with ESMTP id k9DDr8MM008369 for ; Fri, 13 Oct 2006 08:53:09 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Oct 2006 08:53:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Oct 2006 15:53:06 +0200 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 Date: Fri, 13 Oct 2006 15:53:05 +0200 Message-ID: <5D1A7985295922448D5550C94DE291805E4091@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] WG last-call for SIP/SigComp Thread-Index: AcbuzRndN0JXkkp7RxmzKDCgwAGyVwAAPqlA From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 13 Oct 2006 13:53:06.0578 (UTC) FILETIME=[E8F67F20:01C6EECE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Sip] FW: [rohc] WG last-call for SIP/SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) As this document obviously requires SIP expertise to review, please take this as a request for you all to read this draft and send responses to the rohc list (rohc@ietf.org) and the authors, ideally within the timescales of the WGLC.=20 (Note if you are not subscribed to the rohc list then your mail will be held until the list owner reviews it and decides further action) Regards Keith=20 -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: 13 October 2006 14:40 To: rohc@ietf.org Subject: [rohc] WG last-call for SIP/SigComp Soon after the publication of SigComp (RFC 3320), work with a document defining the specifics of using SigComp for SIP message compression was initialised. For various reasons, the finalisation of this document has taken much more time than anticipated, but me and the authors now believe it should be ready for publication. This is an essential document for the application of SigComp on SIP, and it is thus important that we finally get it out of the pipe. We are therefore now issuing a working group last-call on the following document: =20 draft-ietf-rohc-sigcomp-sip-03.txt (for publication as Proposed Standard) =20 This will be the usual two-week WG last-call as suggested in RFC 2418. Please direct last-call comments to the ROHC mailing list rohc@ietf.org before Fri, 2006-10-27, 18:00 UTC. =20 /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 8 404 29 61 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 13 11:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYOmL-0007WZ-BC; Fri, 13 Oct 2006 11:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYOmJ-0007WU-0t for sip@ietf.org; Fri, 13 Oct 2006 11:16:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYOmG-00018n-MF for sip@ietf.org; Fri, 13 Oct 2006 11:16:51 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2006 08:16:48 -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 k9DFGmBp015797 for ; Fri, 13 Oct 2006 08:16:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9DFGlAo014768 for ; Fri, 13 Oct 2006 08:16:47 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Oct 2006 08:16:47 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 08:16:47 -0700 Message-ID: <452FADDE.3040400@cisco.com> Date: Fri, 13 Oct 2006 11:16:46 -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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2006 15:16:47.0562 (UTC) FILETIME=[99B3DAA0:01C6EEDA] DKIM-Signature: a=rsa-sha1; q=dns; l=1656; t=1160752608; x=1161616608; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:New=20draft=20on=20mid-dialog=20failover=20and=20proxy=20discovery=20in= 20SIP=20outbound; X=v=3Dcisco.com=3B=20h=3D83m5TUr8YKSMUatjYkKs9VtreVk=3D; b=WchcEsDQmJ2ZTWBzC7WmDS3xxOTmOkYiYUP+NGNkav77DVFGjZ+kYb5IBW5LDVF9r7WMnSx1 DK3Zxhm/WBoz8BJvRSVl44wjRuFHb9zKH+TVO0rewHBiw6RhIlCLKwO4; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] New draft on mid-dialog failover and proxy discovery in SIP 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 I've just submitted a new draft that proposes a solution for outbound proxy discovery and mid-dialog failover with SIP outbound. I hinted at this solution last IETF meeting. The mechanism requires no state replication in edge proxies, no DNS changes or configurations (if anythign it simplifies it further from even normal SIP), is backwards compatible with home proxies that don't support it, and allows folks to continue to place stuff into record-routes and see it back again for mid-dialog requests that get routed to backups. As an interesting side effect, the mechanism also results in TCP/TLS connection reuse which *does* work through NAT (unlike the existing connect-reuse draft which does not), and addresses many of the problems identified in Vijay's domain-certs document. It allows SIP proxies to work more like the web model where you just need a single cert like 'proxies.example.com' for the entire cluster and no other hostname or IP address except this one is used. I admit its not an easy read; the mechanism itself is not too hard to describe or implement; its much more complicated to explain why it works. Until it appears in the archives you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt 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 Fri Oct 13 12:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQ2n-0006yj-Dy; Fri, 13 Oct 2006 12:37:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYQ2l-0006yO-Pp for sip@ietf.org; Fri, 13 Oct 2006 12:37:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYQ2j-0000Ss-Cv for sip@ietf.org; Fri, 13 Oct 2006 12:37:55 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 13 Oct 2006 09:37:53 -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 k9DGbqdw017433 for ; Fri, 13 Oct 2006 09:37:52 -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 k9DGbibj025110 for ; Fri, 13 Oct 2006 09:37:52 -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, 13 Oct 2006 09:37:12 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Oct 2006 09:37:12 -0700 Message-ID: <452FC0B7.6030007@cisco.com> Date: Fri, 13 Oct 2006 12:37: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2006 16:37:12.0134 (UTC) FILETIME=[D55F1E60:01C6EEE5] DKIM-Signature: a=rsa-sha1; q=dns; l=894; t=1160757472; x=1161621472; 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:New=20I-D=20on=20UA=20loose=20routing; X=v=3Dcisco.com=3B=20h=3Dpv9SXVhom8VNB5N1k49Z+4EcVE0=3D; b=dj7YqBorRk8AJiAAuCvAfbHMaSgUfeBgrr6JSsDZm1rluOc4PPLS9ItB9NR6MrqQ42iAJNqr AmrYsOJWDPVMyo+3eLGDFtWt6hcjKVH4DAr8cK2EFhg3Sgw2vNAPMc90; 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: d6b246023072368de71562c0ab503126 Subject: [Sip] New I-D on UA loose routing X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted a new I-D which describes this concept of UA loose routing that we've been discussing on the list. This fell out of the GRUU discussions as an alternative solution for grid. As the draft explains, the mechanism also solves many other problems, like sub-addressing, limited use adresses, 8xx number usage, and is even required for proper 911/emergency services operation with ecrit. Until the draft appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt 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 Fri Oct 13 13:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRCs-0002Iu-DQ; Fri, 13 Oct 2006 13:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRCq-0002Ij-Ew for sip@ietf.org; Fri, 13 Oct 2006 13:52:24 -0400 Received: from prufrock.cs.umd.edu ([128.8.128.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRCo-0005mS-6E for sip@ietf.org; Fri, 13 Oct 2006 13:52:24 -0400 Received: (from sharno@localhost) by prufrock.cs.umd.edu (8.12.10/8.12.5) id k9DHqMg9022823 for sip@ietf.org; Fri, 13 Oct 2006 13:52:22 -0400 (EDT) Date: Fri, 13 Oct 2006 13:52:22 -0400 (EDT) From: Tamer Elsharnouby Message-Id: <200610131752.k9DHqMg9022823@prufrock.cs.umd.edu> To: sip@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Sip] IEEE NetCri 2007: Call for papers X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ** Apologies if you receive multiple copies of this call for papers ** =============================================================================== Call for Papers NetCri 07 The First International Workshop on Research Challenges in Next Generation Networks for First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri In Conjunction with IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =============================================================================== As advances in pervasive computing, wireless communication and sensor networks continue, more opportunities are open to first responders and critical infra- structures to benefit from these technologies. Providing first responders with the best possible technology, infrastructure and services help save the lives of the general public and the first responders as well. One of the main challenges to the operations of first responders and critical infrastructures is to deploy a communication network that is dependable, secure, and rapidly deployable. In order to operate effectively, the deployed network supports services such as location determination, audio and video communication, and in site and remote sensing. Another key feature for first responders and critical infrastructures networks is to support interactions among multiple heterogen- eous networks. This workshop provides a forum for researchers, industry, and government agencies to discuss the challenges facing the design, deployment and operation- al issues for next generation network support for first responders and critical infrastructure. The workshop will identify and define fundamental concepts and techniques, resolve conflicts between different approaches in the area, and provide a common ground for an advanced research and development agenda. Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.) - Fast roaming in heterogonous network environment - Localization and time synchronization - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time control - Network and system support for augmented reality and visual analytics - Simulation studies of first responders and critical infrastructures’ networks - Novel and adaptive communication protocols to support first responders and critical infrastructure’ operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not currently under review by another conference, workshop, or journal. Authors are invited to submit a maximum of 6 pages papers including the abstract, figures and references. Papers should include the title, author(s), authors' affiliation and an abstract. The formatting should be according to IEEE rules. Papers should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and are included in the conference proceedings. Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, 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 Oct 14 05:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYg33-0007js-L1; Sat, 14 Oct 2006 05:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYg30-0007ja-Uf for sip@ietf.org; Sat, 14 Oct 2006 05:43:14 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYg2q-0000dT-AU for sip@ietf.org; Sat, 14 Oct 2006 05:43:14 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B977223; Sat, 14 Oct 2006 11:42:52 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 11:42:52 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 11:42:52 +0200 Received: from [131.160.126.113] (rvi2-126-113.lmf.ericsson.se [131.160.126.113]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2770E251E; Sat, 14 Oct 2006 12:42:52 +0300 (EEST) Message-ID: <4530B11A.2080302@ericsson.com> Date: Sat, 14 Oct 2006 12:42:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: jbemmel@zonnet.nl Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> In-Reply-To: <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2006 09:42:52.0192 (UTC) FILETIME=[1E1AC200:01C6EF75] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "sip@ietf.org" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, > Major technical comment on section 5.8: the proposed Trigger-Consent > mechanism looks like one big hack to me. It does not comply with > RFC3515, and appears to be an inappropriate use of REFER. Suggestion: > use SUBSCRIBE / NOTIFY we cannot use SUBSCRIBE/NOTIFY because the entity receiving the original request may not have any means to authenticate itself to the relay that stores the permission. That's why we need to be able to use the return routability mechanism described in the draft. The mechanism to trigger a new MESSAGE request with a permission document towards the recipient needs to: 1) inform the recipient about the recipient URI of the translation 2) provide a SIP URI that, if touched, will trigger a new MESSAGE request. Therefore, an alternative solution (which was discussed in the past) to the REFER approach would be to define the Trigger-Consent header field so that it contains the recipient URI of the translation and a SIP URI. The recipient would send a PUBLISH request (instead of a REFER) to that URI to trigger a new MESSAGE request with a permission document. The reason why the Trigger-Consent header field needs to carry the recipient URI of the translation is because a request can go through more than one translation before reaching the recipient. > Technical comment on Trigger-Consent: the ABNF in section 5.11 allows > multiple instances of this header. Is this desired? I answered this above. If folks prefer this PUBLISH-based solution over the REFER-based solution I can edit the draft accordingly. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 14 14:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnsb-0004EF-9L; Sat, 14 Oct 2006 14:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYnsZ-0004EA-IT for sip@ietf.org; Sat, 14 Oct 2006 14:04:59 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnsY-0002X5-4A for sip@ietf.org; Sat, 14 Oct 2006 14:04:59 -0400 Received: (qmail 14704 invoked by uid 0); 14 Oct 2006 18:04:27 -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 < >; 14 Oct 2006 18:04:27 -0000 Message-ID: <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Gonzalo Camarillo" References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 Date: Sat, 14 Oct 2006 20:04:31 +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: 1.1 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, Thanks for your response. What I had in mind when I suggested SUBSCRIBE/NOTIFY is the following: the relay adds a Trigger-Consent header as described, using a return routeability test (ie random username, etc). The receiving client then SUBSCRIBEs to that URI, for a TBD event package, providing a Contact as usual. The relay then sends a NOTIFY to the client Contact, with a body containing the permission document I believe this scheme has similar security properties as the REFER/MESSAGE scheme. A difference is that the permission document gets sent to a Contact address instead of an AoR, which seems desirable (if not, how do you ensure that it gets sent to the same UA as the INVITE?) Regards, Jeroen Gonzalo Camarillo wrote: > Hi, > >> Major technical comment on section 5.8: the proposed Trigger-Consent >> mechanism looks like one big hack to me. It does not comply with >> RFC3515, and appears to be an inappropriate use of REFER. Suggestion: >> use SUBSCRIBE / NOTIFY > > we cannot use SUBSCRIBE/NOTIFY because the entity receiving the > original request may not have any means to authenticate itself to the > relay that stores the permission. That's why we need to be able to > use the return routability mechanism described in the draft. > > The mechanism to trigger a new MESSAGE request with a permission > document towards the recipient needs to: > > 1) inform the recipient about the recipient URI of the translation > 2) provide a SIP URI that, if touched, will trigger a new MESSAGE > request. > Therefore, an alternative solution (which was discussed in the past) > to the REFER approach would be to define the Trigger-Consent header > field so that it contains the recipient URI of the translation and a SIP > URI. The recipient would send a PUBLISH request (instead of a REFER) > to that URI to trigger a new MESSAGE request with a permission > document. > The reason why the Trigger-Consent header field needs to carry the > recipient URI of the translation is because a request can go through > more than one translation before reaching the recipient. > >> Technical comment on Trigger-Consent: the ABNF in section 5.11 allows >> multiple instances of this header. Is this desired? > > I answered this above. > > If folks prefer this PUBLISH-based solution over the REFER-based > solution I can edit the draft accordingly. > > Cheers, > > Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 14 14:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYo9R-00074g-Qt; Sat, 14 Oct 2006 14:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYo9Q-00073G-6h for sip@ietf.org; Sat, 14 Oct 2006 14:22:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYnyF-0003JT-Lm for sip@ietf.org; Sat, 14 Oct 2006 14:11:00 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B0F44F0001; Sat, 14 Oct 2006 20:09:32 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 20:09:32 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Oct 2006 20:09:31 +0200 Received: from [131.160.126.113] (rvi2-126-113.lmf.ericsson.se [131.160.126.113]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BE98B251E; Sat, 14 Oct 2006 21:09:31 +0300 (EEST) Message-ID: <453127D9.804@ericsson.com> Date: Sat, 14 Oct 2006 21:09:29 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> In-Reply-To: <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2006 18:09:31.0969 (UTC) FILETIME=[E5C89B10:01C6EFBB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, there is a mechanism for relays to send permission documents to recipients. Creating a second one is not a good idea. We need to reuse that mechanism. In any case, what you are proposing seems like the same mechanism changing the methods. Instead of a PUBLISH followed by a MESSAGE you would have a SUBSCRIBE followed by a NOTIFY. Therefore, I believe that the PUBLISH-based solution meets your requirements and, additionally, reuses the mechanisms already defined in the framework. If nobody objects I will edit the draft accordingly. Thanks, Gonzalo Jeroen van Bemmel wrote: > Gonzalo, > > Thanks for your response. > > What I had in mind when I suggested SUBSCRIBE/NOTIFY is the > following: the relay adds a Trigger-Consent header as described, > using a return routeability test (ie random username, etc). The > receiving client then SUBSCRIBEs to that URI, for a TBD event > package, providing a Contact as usual. The relay then sends a NOTIFY > to the client Contact, with a body containing the permission document > > > I believe this scheme has similar security properties as the > REFER/MESSAGE scheme. A difference is that the permission document > gets sent to a Contact address instead of an AoR, which seems > desirable (if not, how do you ensure that it gets sent to the same UA > as the INVITE?) > > Regards, Jeroen > > Gonzalo Camarillo wrote: >> Hi, >> >>> Major technical comment on section 5.8: the proposed >>> Trigger-Consent mechanism looks like one big hack to me. It does >>> not comply with RFC3515, and appears to be an inappropriate use >>> of REFER. Suggestion: use SUBSCRIBE / NOTIFY >> >> we cannot use SUBSCRIBE/NOTIFY because the entity receiving the >> original request may not have any means to authenticate itself to >> the relay that stores the permission. That's why we need to be able >> to use the return routability mechanism described in the draft. >> >> The mechanism to trigger a new MESSAGE request with a permission >> document towards the recipient needs to: >> >> 1) inform the recipient about the recipient URI of the translation >> 2) provide a SIP URI that, if touched, will trigger a new MESSAGE >> request. Therefore, an alternative solution (which was discussed in >> the past) to the REFER approach would be to define the >> Trigger-Consent header field so that it contains the recipient URI >> of the translation and a SIP URI. The recipient would send a >> PUBLISH request (instead of a REFER) to that URI to trigger a new >> MESSAGE request with a permission document. The reason why the >> Trigger-Consent header field needs to carry the recipient URI of >> the translation is because a request can go through more than one >> translation before reaching the recipient. >> >>> Technical comment on Trigger-Consent: the ABNF in section 5.11 >>> allows multiple instances of this header. Is this desired? >> >> I answered this above. >> >> If folks prefer this PUBLISH-based solution over the REFER-based >> solution I can edit the draft accordingly. >> >> Cheers, >> >> Gonzalo > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 14 16:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqKf-0007jp-QF; Sat, 14 Oct 2006 16:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYqKe-0007jk-EX for sip@ietf.org; Sat, 14 Oct 2006 16:42:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYqKd-0001w4-0q for sip@ietf.org; Sat, 14 Oct 2006 16:42:08 -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 k9EKfvI10927; Sat, 14 Oct 2006 16:41:57 -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: Sat, 14 Oct 2006 15:41:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0D8A90AF@zrc2hxm0.corp.nortel.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Thread-Index: AcbvAdlfqxzCdf37QJGyUamKx3+0KgAzR4yA From: "Francois Audet" To: , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Subject: [Sip] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.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 Jonathan, Good job with this draft. Here are some comments on it. There is one case not mentioned in this draft that I think should be discussed. It is somewhat similar to your 1-800 number. It is very common in PSTN to be reachable by more than one phone numbers. Of particular importance is the case of Enterprise users who typically have both an E.164 Public number and one or more Private corporate numbers (typically, a "long" corporate-wide number valid in phone-context=3Dexpample.com and also a "short" number valid in a specific location such as phone-context=3D santaclara.example.com). Similar arrangements also exist in Public networks (like your 1-800 example). The difference is that in Enterprises, it is almost always the case that multiple numbers are supported. Seems to me this should be discussed in the draft. Now, there is some additional complexity to consider here. Typically, a SIP UA (such as a SIP phone) will be configured with it's AOR consisting of a username and domain name (sip:user1@example.com). It only "knows" of one of that identity. That identity could be an alphanumeric username, or it could even look like a phone number (typical with low-end SIP phone installations). The problem is that it is unlikely that these devices will "know" all the possible phone numbers assigned to them as this is normally centrally configured. And a phone will not normally accept arbitrary requests to URIs it doesn't understand (otherwise, a device supporting multiple users wouldn't know which line appearance/user the request is targetted to). It could also be bad for SPIT. I guess the solution to this would be for such an endpoint to rely on the Route header for such purpose instead of the Request-URI. This was probably your intention, but maybe making it explicit would be useful. Another suggestion is to add a URI parameter to the example. One of the main benefits of this draft is to preserve URI parameters potentially useful for the target (as we discussed on the mailing list). A mention of this in the draft would be quite useful. Cheers. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, October 13, 2006 12:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Applying Loose Routing to Session=20 > Initiation Protocol (SIP) User Agents (UA) > Author(s) : J. Rosenberg > Filename : draft-rosenberg-sip-ua-loose-route-00.txt > Pages : 20 > Date : 2006-10-13 > =09 > A key part of the behavior of the Session Initiation Protocol (SIP) > is that SIP proxies rewrite the Request-URI as a request moves > throughout the network. Over the years, experience has=20 > shown this to > be problematic. It makes it difficult to use Request URI=20 > for service > invocation, complicates emergency services, makes it more=20 > complex to > support aliases, and so on. Architecturally, it confounds the > concepts of address and route. This document proposes to=20 > change this > through a new mechanism called UA loose routing. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > se-route-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-rosenberg-sip-ua-loose-route-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=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 Sat Oct 14 17:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYrDO-0007Jp-Mc; Sat, 14 Oct 2006 17:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYrDN-0007Jh-9g for sip@ietf.org; Sat, 14 Oct 2006 17:38:41 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYrDL-0003NR-Qg for sip@ietf.org; Sat, 14 Oct 2006 17:38:41 -0400 Received: (qmail 1452 invoked by uid 0); 14 Oct 2006 21:39:48 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Oct 2006 21:39:48 -0000 Message-ID: <006901c6efd9$18a4c0f0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Gonzalo Camarillo" References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> <453127D9.804@ericsson.com> Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 Date: Sat, 14 Oct 2006 23:38:32 +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: 1.1 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, I agree that PUBLISH is an improvement over REFER, although a PUBLISH with an empty body is uncommon. Another alternative could be a new 6xx response code (or a new header to be used in an error response), i.e. one meaning "Decline and please send me the permissions document again." Perhaps it is already intended, but the current text in section 5.8 does not spell out that the URI in the Trigger-Consent header should be hard to guess (to prevent a DoS attack in which an attacker requests someone elses permissions document, and then revokes relay permissions). Ideally, it would not even contain the target towards which the permissions documents will get sent. The relay could encode this association into the URI, such that an attacker cannot change the target The above works better with PUBLISH, the information that would normally go in the Refer-To header can then remain implicit Regards, Jeroen Gonzalo Camarillo wrote: > Hi, > > there is a mechanism for relays to send permission documents to > recipients. Creating a second one is not a good idea. We need to reuse > that mechanism. > > In any case, what you are proposing seems like the same mechanism > changing the methods. Instead of a PUBLISH followed by a MESSAGE you > would have a SUBSCRIBE followed by a NOTIFY. > > Therefore, I believe that the PUBLISH-based solution meets your > requirements and, additionally, reuses the mechanisms already defined > in the framework. > > If nobody objects I will edit the draft accordingly. > > Thanks, > > Gonzalo > > > Jeroen van Bemmel wrote: >> Gonzalo, >> >> Thanks for your response. >> >> What I had in mind when I suggested SUBSCRIBE/NOTIFY is the >> following: the relay adds a Trigger-Consent header as described, >> using a return routeability test (ie random username, etc). The >> receiving client then SUBSCRIBEs to that URI, for a TBD event >> package, providing a Contact as usual. The relay then sends a NOTIFY >> to the client Contact, with a body containing the permission document >> >> >> I believe this scheme has similar security properties as the >> REFER/MESSAGE scheme. A difference is that the permission document >> gets sent to a Contact address instead of an AoR, which seems >> desirable (if not, how do you ensure that it gets sent to the same UA >> as the INVITE?) >> >> Regards, Jeroen >> >> Gonzalo Camarillo wrote: >>> Hi, >>> >>>> Major technical comment on section 5.8: the proposed >>>> Trigger-Consent mechanism looks like one big hack to me. It does >>>> not comply with RFC3515, and appears to be an inappropriate use >>>> of REFER. Suggestion: use SUBSCRIBE / NOTIFY >>> >>> we cannot use SUBSCRIBE/NOTIFY because the entity receiving the >>> original request may not have any means to authenticate itself to >>> the relay that stores the permission. That's why we need to be able >>> to use the return routability mechanism described in the draft. >>> >>> The mechanism to trigger a new MESSAGE request with a permission >>> document towards the recipient needs to: >>> >>> 1) inform the recipient about the recipient URI of the translation >>> 2) provide a SIP URI that, if touched, will trigger a new MESSAGE >>> request. Therefore, an alternative solution (which was discussed in >>> the past) to the REFER approach would be to define the >>> Trigger-Consent header field so that it contains the recipient URI >>> of the translation and a SIP URI. The recipient would send a >>> PUBLISH request (instead of a REFER) to that URI to trigger a new >>> MESSAGE request with a permission document. The reason why the >>> Trigger-Consent header field needs to carry the recipient URI of >>> the translation is because a request can go through more than one >>> translation before reaching the recipient. >>> >>>> Technical comment on Trigger-Consent: the ABNF in section 5.11 >>>> allows multiple instances of this header. Is this desired? >>> >>> I answered this above. >>> >>> If folks prefer this PUBLISH-based solution over the REFER-based >>> solution I can edit the draft accordingly. >>> >>> Cheers, >>> >>> Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 14 19:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYt4u-0005FA-Qh; Sat, 14 Oct 2006 19:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYt4t-0005F5-En for sip@ietf.org; Sat, 14 Oct 2006 19:38:03 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYt4s-0005Zv-3U for sip@ietf.org; Sat, 14 Oct 2006 19:38:03 -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 k9ENVBi28087; Sat, 14 Oct 2006 19:31:11 -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] I-D on handling large UDP responses Date: Sat, 14 Oct 2006 18:37:48 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@zrc2hxm2.corp.nortel.com> In-Reply-To: <200610051558.k95Fw6cg002307@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: Acbol01InSgU795+SVS8DGPx9e54hgAQhfvA From: "Samir Srivastava" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 really want a fool proof solution, then we should look into Path MTU discovery work. More complications. The more, we want to fix unreliability/fragmentation etc in SIP, the more problems we are inviting. In spite of current UDP installed base, I am for deprecating UDP. Do we really need to have exception for MESSAGE where it is useful ? Unreliable transports raises the another question of DTLS. Thx Samir > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Thursday, October 05, 2006 8:58 AM > To: sip@ietf.org > Subject: Re: [Sip] I-D on handling large UDP responses >=20 > From: "Vijay K. Gurbani" >=20 > > We might be able to reduce the number of 140's by having the proxy in > > question add a (short!) parameter to the Via of the outgoing request > > indicating "140 already sent for this request". Then a proxy would > > not generate a 140 for a request that had this flag on a Via. >=20 > This is interesting -- but if a proxy, P1, switches to TCP from UDP, > and sends a 140, then chances are that all proxies downstream from > P1 will use TCP as well (for the same reason that P1 did -- the > request was over 1500 bytes). >=20 > So, a 140 should happen only once, and not at every hop. >=20 > That requires that all the proxies have the same idea what the UDP > limit is (and that the request isn't modified enough to shrink at any > step). That can be satisfied if all the proxies have the same idea of > the path MTU. Is that a reasonable assumption? Or maybe the more > reasonable assumption that *none* of the proxies know what the path > MTU is, and all of them use 1500. >=20 > Dale >=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 Oct 14 23:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwFU-0006VM-Kg; Sat, 14 Oct 2006 23:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwFT-0006VH-Fk for sip@ietf.org; Sat, 14 Oct 2006 23:01:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYwFQ-0004kJ-5x for sip@ietf.org; Sat, 14 Oct 2006 23:01:11 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9F24PMo001520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Oct 2006 21:04:25 -0500 Message-ID: <4531A5F5.9010905@softarmor.com> Date: Sat, 14 Oct 2006 22:07:33 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en 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: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Note To Sender Address Verification Users X-BeenThere: sip@ietf.org X-Mailman-Version: 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 note to list subscribers: If you're using Sender Address Verification (like ditech is apparently now doing) you can expect to receive no mail from me. Have a nice day. -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 14 23:08:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwKi-0000yN-Oq; Sat, 14 Oct 2006 23:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwKi-0000yH-1g for sip@ietf.org; Sat, 14 Oct 2006 23:06:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYwKf-0005VP-A5 for sip@ietf.org; Sat, 14 Oct 2006 23:06:36 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9F29oGf001565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Oct 2006 21:09:50 -0500 Message-ID: <4531A73A.3020502@softarmor.com> Date: Sat, 14 Oct 2006 22:12:58 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] I-D on handling large UDP responses References: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@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: 30ac594df0e66ffa5a93eb4c48bcb014 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: > If we really want a fool proof solution, then we should look into Path > MTU discovery work. More complications. If you think any known technique for path MU discovery is foolproof, you must have a very modest idea of "fools". -- 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 Oct 14 23:25:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwah-00081G-Qc; Sat, 14 Oct 2006 23:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYwag-0007z5-KU for sip@ietf.org; Sat, 14 Oct 2006 23:23:06 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYwaf-00080k-Ay for sip@ietf.org; Sat, 14 Oct 2006 23:23:06 -0400 Received: from [192.168.2.104] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9F2QMK9001611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Oct 2006 21:26:23 -0500 Message-ID: <4531AB1A.5000308@softarmor.com> Date: Sat, 14 Oct 2006 22:29:30 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samir Srivastava Subject: Re: [Sip] I-D on handling large UDP responses References: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@zrc2hxm2.corp.nortel.com> <4531A73A.3020502@softarmor.com> In-Reply-To: <4531A73A.3020502@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Dean Willis wrote: > Samir Srivastava wrote: > >> If we really want a fool proof solution, then we should look into Path >> MTU discovery work. More complications. > > > If you think any known technique for path MU discovery is foolproof, you > must have a very modest idea of "fools". > er, MTU. Clearly, I'm a fool . . . -- 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 Oct 15 02:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYzWc-0004Zn-SV; Sun, 15 Oct 2006 02:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYzWb-0004ZZ-Jz for sip@ietf.org; Sun, 15 Oct 2006 02:31:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYzWR-0000aH-LH for sip@ietf.org; Sun, 15 Oct 2006 02:31:05 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ACE0F1BF; Sun, 15 Oct 2006 08:30:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 08:30:44 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 08:30:43 +0200 Received: from [131.160.126.113] (rvi2-126-113.lmf.ericsson.se [131.160.126.113]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E79052441; Sun, 15 Oct 2006 09:30:43 +0300 (EEST) Message-ID: <4531D591.2040409@ericsson.com> Date: Sun, 15 Oct 2006 09:30:41 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> <453127D9.804@ericsson.com> <006901c6efd9$18a4c0f0$0601a8c0@BEMBUSTER> In-Reply-To: <006901c6efd9$18a4c0f0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2006 06:30:44.0016 (UTC) FILETIME=[71307300:01C6F023] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 agree that PUBLISH is an improvement over REFER, although a PUBLISH > with an empty body is uncommon. Another alternative could be a new 6xx > response code (or a new header to be used in an error response), i.e. > one meaning "Decline and please send me the permissions document again." error responses may not reach the relay if there was a proxy between the relay and the recipient. Regarding requests without body, empty HTTP GETs are common when one needs to simply 'touch' a URI, like in this case. > Perhaps it is already intended, but the current text in section 5.8 does > not spell out that the URI in the Trigger-Consent header should be hard > to guess (to prevent a DoS attack in which an attacker requests someone > elses permissions document, and then revokes relay permissions). > Ideally, it would not even contain the target towards which the > permissions documents will get sent. The relay could encode this > association into the URI, such that an attacker cannot change the target The recipient URI appears in the Trigger-Consent header field only for the information of the recipient. The relay will send the MESSAGE with the permission document to the recipient URI of the permission document. Nothing can change that. > The above works better with PUBLISH, the information that would normally > go in the Refer-To header can then remain implicit as I said in my previous posting, that information is there in case a request traverses more than one relay and, thus, gets more than one Trigger-Consent entries. This way, the recipient knows which particular permission each Trigger-Consent entry can revoke. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6R9-0007eO-BW; Sun, 15 Oct 2006 09:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6R7-0007eF-Fh for sip@ietf.org; Sun, 15 Oct 2006 09:53:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6R6-0008Am-2g for sip@ietf.org; Sun, 15 Oct 2006 09:53:53 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:53:51 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp031) with SMTP; 15 Oct 2006 15:53:51 +0200 X-Authenticated: #29516787 Message-ID: <45323D7A.6030201@gmx.net> Date: Sun, 15 Oct 2006 15:54:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] SIP SAML: Issue#8 - SIP SAML Error Response Message X-BeenThere: sip@ietf.org X-Mailman-Version: 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, currently the SIP SAML draft does not specify error responses. This is documented with issue#8: http://www.tschofenig.priv.at:8080/saml-sip/issue8 I would like to take a look at the approach taken by SIP location conveyance to get some guidance on error codes since the mechanisms are very similar (at least they look similar to me). Other suggestions? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Q4-0007GA-8G; Sun, 15 Oct 2006 09:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Q1-0007Ej-VH for sip@ietf.org; Sun, 15 Oct 2006 09:52:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6Q0-0007x8-N2 for sip@ietf.org; Sun, 15 Oct 2006 09:52:45 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:52:43 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp038) with SMTP; 15 Oct 2006 15:52:43 +0200 X-Authenticated: #29516787 Message-ID: <45323D34.3060905@gmx.net> Date: Sun, 15 Oct 2006 15:52:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] SIP SAML: Issue#7 - SAML HTTP-URI-based SIP Binding X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Jonathan gave us comments regarding the profiling of the HTTP SAML binding. See http://www.tschofenig.priv.at:8080/saml-sip/issue7 In a discussion with Jeff I think it is useful to make some additional restrictions here to improve interoperability. I would like to keep the text as is. Objections? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:56:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Pk-0007Di-CH; Sun, 15 Oct 2006 09:52:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Pi-0007Dd-Pe for sip@ietf.org; Sun, 15 Oct 2006 09:52:26 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6Pg-0007ul-Cm for sip@ietf.org; Sun, 15 Oct 2006 09:52:26 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:52:22 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp001) with SMTP; 15 Oct 2006 15:52:22 +0200 X-Authenticated: #29516787 Message-ID: <45323D22.7090700@gmx.net> Date: Sun, 15 Oct 2006 15:52:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] SIP SAML: Issue #5 - Replay Protection: SIP specific Fields in the SAML Assertion X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Jonathan sent us comments regarding replay protection for SIP SAML. We captured the feedback at: http://www.tschofenig.priv.at:8080/saml-sip/issue5 I agree with Jonathan's observation. We should define some new fields that can be carried in the SAML assertion and address this threat. Objections? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:56:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Rd-0007k5-9P; Sun, 15 Oct 2006 09:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Rb-0007k0-Ox for sip@ietf.org; Sun, 15 Oct 2006 09:54:23 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6Ra-0008Fp-C6 for sip@ietf.org; Sun, 15 Oct 2006 09:54:23 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:54:18 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp035) with SMTP; 15 Oct 2006 15:54:18 +0200 X-Authenticated: #29516787 Message-ID: <45323D98.3050300@gmx.net> Date: Sun, 15 Oct 2006 15:54:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value X-BeenThere: sip@ietf.org X-Mailman-Version: 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, we had some discussions about a SIP proxy adding a SAML assertion to the SIP header. See issue#9 at http://www.tschofenig.priv.at:8080/saml-sip/issue9 The SIP Payment draft defines a profile that allows SAML assertions to be added by the end point. I suggest to consider the SIP Payment mechanism. I am not so sure whether we should move the content of the SIP Payment draft into the SIP SAML draft. I would prefer to keep the functionality of the end host to request SAML assertions in the SIP Payment draft for now. This also refers to issue#10. http://www.tschofenig.priv.at:8080/saml-sip/issue10 Suggestions? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Rf-0007kk-2N; Sun, 15 Oct 2006 09:54:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Rd-0007k8-DS for sip@ietf.org; Sun, 15 Oct 2006 09:54:25 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6Rb-0008Fz-SS for sip@ietf.org; Sun, 15 Oct 2006 09:54:25 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:54:22 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp019) with SMTP; 15 Oct 2006 15:54:22 +0200 X-Authenticated: #29516787 Message-ID: <45323D9E.9090007@gmx.net> Date: Sun, 15 Oct 2006 15:54:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] SIP SAML: Issue #11 - Authentication and Authorization Statements in SAML Assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 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, issue#11 points to fact that the current document version only talks about attribute statements. Text is missing to speak about SAMLs usage with respect to authentication and authorization statements. This issue is recorded here http://www.tschofenig.priv.at:8080/saml-sip/issue11 The next version will provide this text. Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 09:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6UE-0001NC-Gi; Sun, 15 Oct 2006 09:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6UC-00019W-Eo for sip@ietf.org; Sun, 15 Oct 2006 09:57:04 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6UB-00006Z-20 for sip@ietf.org; Sun, 15 Oct 2006 09:57:04 -0400 Received: (qmail invoked by alias); 15 Oct 2006 13:57:01 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp040) with SMTP; 15 Oct 2006 15:57:01 +0200 X-Authenticated: #29516787 Message-ID: <45323E3B.5000101@gmx.net> Date: Sun, 15 Oct 2006 15:57:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] SIP SAML: Issue #6 - Restrictions in the Conditions Element X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Jonathan pointed us to the retargeting problem when putting restrictions in the conditions element of a SAML assertion. His feedback can be found at: http://www.tschofenig.priv.at:8080/saml-sip/issue6 I am not quite sure what todo about this issue. I agree that there is a problem with retargeting since this is the entire purpose of the restriction in the conditions element. Maybe we are too restrict here. Feedback on this issue? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 10:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Xr-0004Tv-16; Sun, 15 Oct 2006 10:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ6Xp-0004Tq-BO for sip@ietf.org; Sun, 15 Oct 2006 10:00:49 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZ6Xo-0000vZ-2y for sip@ietf.org; Sun, 15 Oct 2006 10:00:49 -0400 Received: (qmail invoked by alias); 15 Oct 2006 14:00:47 -0000 Received: from ip-80-226-203-40.vodafone-net.de (EHLO [10.227.205.93]) [80.226.203.40] by mail.gmx.net (mp033) with SMTP; 15 Oct 2006 16:00:47 +0200 X-Authenticated: #29516787 Message-ID: <45323F1B.6050308@gmx.net> Date: Sun, 15 Oct 2006 16:00:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] SIP SAML: Issue 1 - Multiple SAML Assertions X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Shida raised issue#1 (see http://www.tschofenig.priv.at:8080/saml-sip/issue1 ) where he points to the need to carry multiple references to SAML assertions in a single SIP message. I think we should support this functionality based on Shida's usage scenario. Objections? Ciao Hannes _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 15 11:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ7Yd-00075H-V8; Sun, 15 Oct 2006 11:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZ7Yc-00075B-O1 for sip@ietf.org; Sun, 15 Oct 2006 11:05:42 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZ7Yb-0006Ic-B8 for sip@ietf.org; Sun, 15 Oct 2006 11:05:42 -0400 Received: (qmail 2186 invoked by uid 0); 15 Oct 2006 15:06:48 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 15 Oct 2006 15:06:48 -0000 Message-ID: <002501c6f06b$5bdf0ff0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Gonzalo Camarillo" References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> <453127D9.804@ericsson.com> <006901c6efd9$18a4c0f0$0601a8c0@BEMBUSTER> <4531D591.2040409@ericsson.com> Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 Date: Sun, 15 Oct 2006 17:05:31 +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: 1.1 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, > The recipient URI appears in the Trigger-Consent header field only for > the information of the recipient. The relay will send the MESSAGE with > the permission document to the recipient URI of the permission > document. Nothing can change that. > >> The above works better with PUBLISH, the information that would >> normally go in the Refer-To header can then remain implicit > > as I said in my previous posting, that information is there in case a > request traverses more than one relay and, thus, gets more than one > Trigger-Consent entries. This way, the recipient knows which > particular permission each Trigger-Consent entry can revoke. So you're saying that whatever is in the Refer-To header of the REFER request (following the mechanism in the current draft), is ignored? The relay will send the MESSAGE to the recipient URI? If this information is ignored, I would suggest a different ABNF for the Trigger-Consent header (for use with PUBLISH): Trigger-Consent: ;target="sip:recipient.example.com" This allows the client to know which permission document it applies to, without putting it in the URI (where it is ignored anyway) 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 Sun Oct 15 14:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZARQ-0002D4-G6; Sun, 15 Oct 2006 14:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZARO-0002AT-Jm for sip@ietf.org; Sun, 15 Oct 2006 14:10:26 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZARK-0002pu-Bq for sip@ietf.org; Sun, 15 Oct 2006 14:10:26 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 64F7B6C01C; Sun, 15 Oct 2006 14:10:17 -0400 (EDT) Subject: RE: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60F08BDEE@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 15 Oct 2006 14:10:21 -0400 Message-Id: <1160935821.2898.7.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Sat, 2006-10-14 at 18:37 -0500, Samir Srivastava wrote: > If we really want a fool proof solution, then we should look into Path > MTU discovery work. More complications. I'm not sure which work you're referring to, but I don't think that you're going to get much traction with trying to do more messages before an INVITE just to learn something about the Path MTU (and even if you do, that doesn't ensure that the INVITE will follow the exact same path). > The more, we want to fix unreliability/fragmentation etc in SIP, the > more problems we are inviting. > > In spite of current UDP installed base, I am for deprecating UDP. Do we > really need to have exception for MESSAGE where it is useful ? > Unreliable transports raises the another question of DTLS. >From a practical point of view, getting rid of UDP completely is just not going to happen. Commercial products at least just have to live with it. We should work on making the better transports more widely implemented and otherwise more attractive, but in the mean time it's important that we be able to diagnose when and how UDP is causing problems. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Sun Oct 15 16:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZCFL-0001om-7S; Sun, 15 Oct 2006 16:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZCFJ-0001oX-S2 for sip@ietf.org; Sun, 15 Oct 2006 16:06:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZCF8-0003Di-Ct for sip@ietf.org; Sun, 15 Oct 2006 16:06:05 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 55E891F1; Sun, 15 Oct 2006 22:05:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 22:05:43 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Oct 2006 22:05:42 +0200 Received: from [131.160.126.113] (rvi2-126-113.lmf.ericsson.se [131.160.126.113]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BFDA7232A; Sun, 15 Oct 2006 23:05:42 +0300 (EEST) Message-ID: <45329495.2030209@ericsson.com> Date: Sun, 15 Oct 2006 23:05:41 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> <004801c6efbb$34c90570$0601a8c0@BEMBUSTER> <453127D9.804@ericsson.com> <006901c6efd9$18a4c0f0$0601a8c0@BEMBUSTER> <4531D591.2040409@ericsson.com> <002501c6f06b$5bdf0ff0$0601a8c0@BEMBUSTER> In-Reply-To: <002501c6f06b$5bdf0ff0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2006 20:05:43.0028 (UTC) FILETIME=[4B458B40:01C6F095] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 this information is ignored, I would suggest a different ABNF for the > Trigger-Consent header (for use with PUBLISH): > Trigger-Consent: > ;target="sip:recipient.example.com" yes, this is what I suggested in my previous email. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 04:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZNqq-0004Or-ES; Mon, 16 Oct 2006 04:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZNqn-0004NY-Og for sip@ietf.org; Mon, 16 Oct 2006 04:29:33 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZNnP-0001FC-N8 for sip@ietf.org; Mon, 16 Oct 2006 04:26:09 -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 k9G8JEW14231; Mon, 16 Oct 2006 04:19:14 -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] I-D on handling large UDP responses Date: Mon, 16 Oct 2006 03:25:52 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F08C016@zrc2hxm2.corp.nortel.com> In-Reply-To: <1160935821.2898.7.camel@scott.skrb.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D on handling large UDP responses Thread-Index: AcbwhTQoCwS/yc15SZSVa0UojpHb0AAaaMQA From: "Samir Srivastava" To: "Scott Lawrence" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Scott, I was referring the work being done PMTU group.=20 http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-10.txt I didn't look details of the draft earlier. It does imposes new requirements.=20 Yes. you are correct Path MTU doesn't help completely in the view of alternate routes etc. It is less/more similar in the value as of diagnostic tools. As they MAY not follow the same SIP path as the actual requests.=20 The proposed mechanism can be used only for REQ/RSP. How can we address the problems caused in 200 OK (Offer) and ACK (Answer) due to UDP between some proxies ? In the current model, UAC gets the complete Large 200 OK (with delayed arrival of 140/141 or you change the current solution w.r.t. 140/141), but ACK follows the different IP hops etc... We might be doing congestion handling in SIP for UDP transports in future, where some of it is provided by other transports. In my purist mind, SIP messages are becoming huge, so UDP is no more relevant. UDP was taken initially, as it was simple to transport short SIP message at that time. IMHO, Simplicity wins and It is difficult decision for UDP. Thx Samir -----Original Message----- From: Scott Lawrence [mailto:slawrence@pingtel.com]=20 Sent: Sunday, October 15, 2006 11:10 AM To: Srivastava, Samir (SC100:8826) Cc: sip@ietf.org Subject: RE: [Sip] I-D on handling large UDP responses On Sat, 2006-10-14 at 18:37 -0500, Samir Srivastava wrote: > If we really want a fool proof solution, then we should look into Path > MTU discovery work. More complications. I'm not sure which work you're referring to, but I don't think that you're going to get much traction with trying to do more messages before an INVITE just to learn something about the Path MTU (and even if you do, that doesn't ensure that the INVITE will follow the exact same path). > The more, we want to fix unreliability/fragmentation etc in SIP, the=20 > more problems we are inviting. >=20 > In spite of current UDP installed base, I am for deprecating UDP. Do=20 > we really need to have exception for MESSAGE where it is useful ? > Unreliable transports raises the another question of DTLS. >From a practical point of view, getting rid of UDP completely is just not going to happen. Commercial products at least just have to live with it. We should work on making the better transports more widely implemented and otherwise more attractive, but in the mean time it's important that we be able to diagnose when and how UDP is causing problems. -- Scott Lawrence tel:+1-781-938-5306;ext=3D162 or = sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Mon Oct 16 05:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOrt-0004W9-1r; Mon, 16 Oct 2006 05:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOrr-0004Ut-Mz for sip@ietf.org; Mon, 16 Oct 2006 05:34:43 -0400 Received: from amer-mta08.csc.com ([20.137.52.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOpu-000230-Cp for sip@ietf.org; Mon, 16 Oct 2006 05:32:43 -0400 Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta08.csc.com (Switch-3.1.6/Switch-3.1.0) with ESMTP id k9G9WcB9021929 for ; Mon, 16 Oct 2006 05:32:38 -0400 (EDT) From: Neil Thomson To: sip@ietf.org Message-ID: Date: Mon, 16 Oct 2006 10:31:17 +0100 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 10/16/2006 05:31:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Neil Thomson/GIS/CSC 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 13/10/2006 and will not return until 23/10/2006. For urgent enquiries please contact Jennifer Emms CSC (0141 957 2299 ). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 07:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQDO-0001Xa-E9; Mon, 16 Oct 2006 07:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQDM-0001XQ-R8 for sip@ietf.org; Mon, 16 Oct 2006 07:01:00 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZQDJ-0002Yq-G5 for sip@ietf.org; Mon, 16 Oct 2006 07:01:00 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9GB0qN2007940 for ; Mon, 16 Oct 2006 06:00:52 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 06:00:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Oct 2006 12:59:56 +0200 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 Date: Mon, 16 Oct 2006 12:59:56 +0200 Message-ID: <5D1A7985295922448D5550C94DE291805E444D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 67th IETF Agenda Thread-Index: Acbw/ocEOwAtqyZuQaqSX+HCi3uQWAAE3M8w From: "Drage, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 16 Oct 2006 10:59:56.0895 (UTC) FILETIME=[3777EEF0:01C6F112] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] FW: 67th IETF Agenda X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Please be aware that SIP is scheduled Thursday 13:00 - 15:00 Friday 9:00 - 11:30 Please note that scheduling agenda requests so people can go home early falls pretty low in our considerations. Regards Keith=20 -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org]=20 Sent: 16 October 2006 09:15 To: Working Group Chairs Cc: isrg@isi.edu; bofchairs@ietf.org Subject: 67th IETF Agenda=20 The final agenda can be found at: http://www3.ietf.org/meetings/agenda_67.txt Most, but not all, requests for changes have been made. Marcia _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 10:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTGE-0007a7-BN; Mon, 16 Oct 2006 10:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTGD-0007Zz-2j; Mon, 16 Oct 2006 10:16:09 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTGA-0001I9-8A; Mon, 16 Oct 2006 10:16:09 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9GEFi5F014057; Mon, 16 Oct 2006 17:15:46 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 17:15:37 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 17:15:36 +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 and SigComp Date: Mon, 16 Oct 2006 17:15:36 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02DECFC0@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02CF662D@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Outbound and SigComp Thread-Index: AcbmZD4S3hAOyE29QoCJMZDz3FxVRQAy5EhwABRb5QACaq+r8A== From: To: , , , X-OriginalArrivalTime: 16 Oct 2006 14:15:36.0764 (UTC) FILETIME=[8CF9C7C0:01C6F12D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: rohan@ekabal.com, adam@estacado.net X-BeenThere: sip@ietf.org X-Mailman-Version: 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, It seems to me that the answer I provided to this question is only valid when using UDP. However rohc wg suggests that when using TCP, multiplexing of compressed and not compressed messages should not be done for the same connection: This is what the latest draft-ietf-rohc-sigcomp-sip-03.txt=20 says for UDP: In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to allow both SigComp messages and 'vanilla' SIP messages (i.e. uncompressed SIP messages with no SigComp header) to arrive on the same port. For a message-based transport such as UDP or SCTP, this can be done per message. The receiving endpoint checks the first octet of the UDP/SCTP payload to determine whether the message has been compressed using SigComp. If the MSBs of the octet are "11111" then the message is considered to be a SigComp message and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and is passed directly to the application with no further effect on the SigComp layer. And this is what it says for TCP: For a stream-based transport such as TCP, the distinction is per connection. The receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111" then the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages. Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages then all messages sent over the connection MUST have a SigComp header and be delimited by the use of 0xFFFF as described in [RFC3320]. Note: Appendix A shows how to send uncompressed messages in a SigComp structured TCP connection using a "well-known shim header". Should it for any reason not be desirable to set up more than one TCP connection to a SIP implementation, but the flexibility to send both compressed and uncompressed SIP messages be required, the compressor can set up a SigComp structured connection and send any uncompressed SIP messages using the well-known shim header. Appendix A. Shim header for sending uncompressed messages This appendix presents bytecode that simply instructs the decompressor to output the entire message (effectively sending it uncompressed but within a SigComp message). .... bytecode omitted from this email ... As an implementation optimization, a SigComp implementation MAY compare the initial 13 bytes of each incoming message with the 13 bytes given (the "well-known shim header"), and, in case of a match, simply copy the SigComp message data that follow the shim header without even setting up a UDVM. (Note that, before a SigComp message is formed from the incoming TCP data, the record marking protocol defined in section 4.2.2 of [RFC3320] has to be performed.) To obtain the maximum benefit from this optimization, compressors SHOULD employ exactly the well-known shim header given (and none of the other conceivable byte code sequences for just copying input to output) to send uncompressed data in a SigComp channel. Should this also apply to multiplexing STUN and SIP messages to the same SIP Outbound TCP connection ? If yes it would add 13 bytes of overhead to every single STUN keepalive message that the UA sends "compressed" to the SIP proxy. Regards, Erkki >-----Original Message----- >From: ext sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]=20 >Sent: 04.October.2006 10:02 >To: drage@lucent.com; fluffy@cisco.com; sip@ietf.org >Cc: rohan@ekabal.com; adam@estacado.net >Subject: RE: [Sip] Outbound and SigComp > >=20 >Hi, > >>In summary therefore, I would suggest that as far as the RFCs are >>currently concerned, STUN is outside of SigComp, because noone in the >>STUN community has written a document to put it inside. > >I agree with the approach Keith proposed since in my understanding >it would not make any sense to use SigComp for binary encoded STUN >while according to RFC 3320 SigComp is motivated by compressing text=20 >based protocols: > > Many application protocols used for multimedia communications are > text-based and engineered for bandwidth rich links. As a result the > messages have not been optimized in terms of size.=20 > >STUN messages are size-optimized and small, so you are not expected >to gain much, if anything, by applying SigComp to those. > >However for the SIP Outbound case as both the SIP and STUN messages >must share the same source and destination IP address and port, the=20 >question is if multiplexing STUN messages with SigComp messages can=20 >be safely done. It seems to be possible by checking the two topmost >bits of the message which are always one for SigComp and zero for STUN: > > All SigComp messages contain a prefix (the five=20 >most-significant bits > of the first byte are set to one) that does not occur in UTF-8 > encoded text messages [RFC-2279], so for applications which use this > encoding (or ASCII encoding) it is possible to multiplex=20 >uncompressed > application messages and SigComp messages on the same port. > > The most significant two bits of every STUN message are both zeroes. > This, combined with the magic cookie and the fingerprint attribute, > aid in differentiating STUN packets from other protocols=20 >when STUN is > multiplexed with other protocols on the same port. > >To document this for SIP Outbound deployments using SigComp (like IMS) >could a note be added to the Outbound draft about this ? > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]=20 >>Sent: 04.October.2006 00:12 >>To: Cullen Jennings; SIP; Rohan Mahy; Adam Roach >>Subject: RE: [Sip] Outbound and SigComp >> >>RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an >>application protocol. Therefore in that document there is no=20 >indication >>that SigComp is designed for SIP, or for some other protocol. >> >>RFC 3486 (owned by SIP) specifies how SIP uses SigComp. >> >>On that basis, I would have thought that any group that intended their >>protocol to run over SigComp would need to define how it is used in >>those circumstances, as for usage over any other transport protocol.=20 >> >>In the absence of such a document, usage of SigComp by that protocol >>would be essentially proprietary. >> >>In summary therefore, I would suggest that as far as the RFCs are >>currently concerned, STUN is outside of SigComp, because noone in the >>STUN community has written a document to put it inside. >> >>Views? >> >>Regards >> >>Keith >> >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com]=20 >>> Sent: 02 October 2006 21:46 >>> To: SIP; Rohan Mahy; Adam Roach >>> Subject: [Sip] Outbound and SigComp >>>=20 >>>=20 >>> A question I have been thinking about a little ... what=20 >>> happens when a UA is doing both outbound and sigcomp. Is it=20 >>> clear enough how this happiness? Is stun inside or outside=20 >>> the sigcomp, etc? Anyways, I just wanted to lodge this as an=20 >>> open issue - we probably should check that this is=20 >>> reasonable clear how to do this even if we don't have to say=20 >>> anything about it in outbound. >>>=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 >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Oct 16 13:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWcT-0008Qt-Qv; Mon, 16 Oct 2006 13:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZWcR-0008Ov-Ts for sip@ietf.org; Mon, 16 Oct 2006 13:51:19 -0400 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZWZT-0001AL-NL for sip@ietf.org; Mon, 16 Oct 2006 13:48:17 -0400 Received: from CLHaft@aol.com by imo-d05.mx.aol.com (mail_out_v38_r7.6.) id l.c68.27eeb3d (48576) for ; Mon, 16 Oct 2006 13:48:08 -0400 (EDT) From: CLHaft@aol.com Message-ID: Date: Mon, 16 Oct 2006 13:48:08 EDT To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 Security Edition for Windows sub 5326 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Question on REGISTER X-BeenThere: sip@ietf.org X-Mailman-Version: 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 working on a gateway between a proprietary system and SIP. One of our new projects involves sending REGISTERs on behalf of some of our users to a third party server. They are pointing at section 10.2 of RFC 3261 where it states: UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Does this really mean that our gateway must really wait for a response for one user before we can send a REGISTER for a second user? This is what we are being told by the third-party vendor of the registration server. I find it hard to believe that this is the intent of the RFC, especially since it allows for stateless proxies to be in the path, where they would not be able to do 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 Mon Oct 16 15:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYUW-0008GS-0k; Mon, 16 Oct 2006 15:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYTM-0006Sw-25; Mon, 16 Oct 2006 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYTK-00056b-TG; Mon, 16 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C50BC32899; Mon, 16 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTK-0005td-LX; Mon, 16 Oct 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: Mon, 16 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-xcap-config-00.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 : Extensions to the Session Initiation Protocol (SIP) User Agent Profile Delivery Change Notification Event Package for the Extensible Markup Language Language Configuration Access Protocol (XCAP) Author(s) : D. Petrie Filename : draft-ietf-sip-xcap-config-00.txt Pages : 14 Date : 2006-10-16 The SIP User Agent profile delivery framework describes how a User Agent can retrieve its data using a variety of protocols and defines a SIP event package for notifications of changes to those profiles. This document extends that event package to support XCAP (XML Configuration Access Protocol). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-xcap-config-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-xcap-config-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-xcap-config-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-16135113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-xcap-config-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-xcap-config-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16135113.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 Oct 16 17:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZVr-0005qO-S2; Mon, 16 Oct 2006 16:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZFr-0007br-Ta for sip@ietf.org; Mon, 16 Oct 2006 16:40:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYvn-0000sJ-3O for sip@ietf.org; Mon, 16 Oct 2006 16:19:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Oct 2006 13:19:27 -0700 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 k9GKJQ3f024019; Mon, 16 Oct 2006 16:19:26 -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 k9GKJQDM015991; Mon, 16 Oct 2006 16:19:26 -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, 16 Oct 2006 16:19:26 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 16:19:26 -0400 Message-ID: <4533E94F.3090505@cisco.com> Date: Mon, 16 Oct 2006 16:19:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: CLHaft@aol.com Subject: Re: [Sip] Question on REGISTER References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 20:19:26.0196 (UTC) FILETIME=[6054C340:01C6F160] DKIM-Signature: a=rsa-sha1; q=dns; l=1692; t=1161029966; x=1161893966; 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=20on=20REGISTER |To:CLHaft@aol.com; X=v=3Dcisco.com=3B=20h=3DyDooipuEhcCESUaMNqXytABoo9o=3D; b=XVHcLrAmnEkgJVo55lzNwSyFxRp/ASsVmr4qZ09L5lfu716Fl58sTi+JJ9LKKm30LSefibtt E+pZ6VnPWR7oxfy7RF7+fixRdQ/R02ERR+//qpzIkZE3jDGry4zLHRlX; 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: 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 CLHaft@aol.com wrote: > I'm working on a gateway between a proprietary system and SIP. One of our > new projects involves sending REGISTERs on behalf of some of our users to a > third party server. They are pointing at section 10.2 of RFC 3261 where it > states: > > UAs MUST NOT send a new registration (that is, containing new Contact > header field values, as opposed to a retransmission) until they have > received a final response from the registrar for the previous one or > the previous REGISTER request has timed out. > > Does this really mean that our gateway must really wait for a response for > one user before we can send a REGISTER for a second user? Nah, that's BS. This prohibition applies to a single UA. You should view your gateway as being logically a bunch of UAs, one for each user it represents and registers. This is true for a "two line phone" as well. The registrations for the two lines are separate. BTW, in the future you should send such queries to sip-implementors@cs.columbia.edu. Paul > This is what we are > being told by the third-party vendor of the registration server. I find it > hard to believe that this is the intent of the RFC, especially since it allows > for stateless proxies to be in the path, where they would not be able to do > 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 mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 17:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZa7s-0008C9-N2; Mon, 16 Oct 2006 17:36:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZZFX-0002VM-0E for sip@ietf.org; Mon, 16 Oct 2006 16:39:51 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZZ1z-0001xJ-6Q for sip@ietf.org; Mon, 16 Oct 2006 16:25:52 -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 k9GKPdh05172; Mon, 16 Oct 2006 16:25:39 -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] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Date: Mon, 16 Oct 2006 15:25:39 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110F1F889@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D8A90AF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Thread-Index: AcbvAdlfqxzCdf37QJGyUamKx3+0KgAzR4yAAGQFGJA= From: "Brian Stucker" To: "Francois Audet" , , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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 Jonathan, Thanks for chronicling the discussion into a draft. Just to build from Francois' comments (still reading through the entire draft)... If the UA is to look at the Route header to get the identity at which it should accept the the request because the Request-URI could be who knows what, isn't this confabulating the purposes of the two headers? We'd be using a routing header for identity purposes. >From section 4.2, you mention that the exact purpose of the Route header is to indicate the next hop of the request, but now it would also have to be the identity at that next hop that you're wishing to be contacted as well. This assumes, of course, that Francois' concern about the reliability of the Request-URI value (when you take into account limited UA behavior) pans out (which I think it will). Thoughts? Also, the comment at the bottom of section 4.2 about H-I seemed prejudicial/self-conflicting: "Thirdly, the history specification is fairly complex and has seen limited industry adoption. This should never be a reason to not use a mechanism when its the right choice, but its a consideration that warrants mentioning." If something should never be a reason to exclude a mechanism then why is it a consideration?=20 SIP is fairly complex, and given the relative scope of the H-I mechanism, I'm sure we can find plenty of examples of other mechanisms proposed within/for SIP that have similar current adoption rates. Regards, Brian > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Saturday, October 14, 2006 3:42 PM > To: sip@ietf.org; Jonathan Rosenberg > Subject: [Sip] RE: I-D=20 > ACTION:draft-rosenberg-sip-ua-loose-route-00.txt >=20 > Hi Jonathan, >=20 > Good job with this draft. Here are some comments on it. >=20 > There is one case not mentioned in this draft that I think=20 > should be discussed. It is somewhat similar to your 1-800 number. >=20 > It is very common in PSTN to be reachable by more than one=20 > phone numbers. >=20 > Of particular importance is the case of Enterprise users who=20 > typically have both an E.164 Public number and one or more=20 > Private corporate numbers (typically, a "long" corporate-wide=20 > number valid in phone-context=3Dexpample.com and also a "short"=20 > number valid in a specific location such as phone-context=3D=20 > santaclara.example.com). Similar arrangements also exist in=20 > Public networks (like your 1-800 example). The difference is=20 > that in Enterprises, it is almost always the case that=20 > multiple numbers are supported. >=20 > Seems to me this should be discussed in the draft. >=20 > Now, there is some additional complexity to consider here.=20 > Typically, a SIP UA (such as a SIP phone) will be configured=20 > with it's AOR consisting of a username and domain name=20 > (sip:user1@example.com). It only "knows" of one of that identity. > That identity could be an alphanumeric username, or it could=20 > even look like a phone number (typical with low-end SIP phone=20 > installations). >=20 > The problem is that it is unlikely that these devices will=20 > "know" all the possible phone numbers assigned to them as=20 > this is normally centrally configured. > And a phone > will not normally accept arbitrary requests to URIs it=20 > doesn't understand (otherwise, a device supporting multiple=20 > users wouldn't know which line appearance/user the request is=20 > targetted to). It could also be bad for SPIT. >=20 > I guess the solution to this would be for such an endpoint to=20 > rely on the Route header for such purpose instead of the=20 > Request-URI. This was probably your intention, but maybe=20 > making it explicit would be useful. >=20 > Another suggestion is to add a URI parameter to the example.=20 > One of the main benefits of this draft is to preserve URI=20 > parameters potentially useful for the target (as we discussed=20 > on the mailing list). A mention of this in the draft would be=20 > quite useful. >=20 > Cheers. >=20 >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Friday, October 13, 2006 12:50 PM > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : Applying Loose Routing to Session=20 > > Initiation Protocol (SIP) User Agents (UA) > > Author(s) : J. Rosenberg > > Filename : draft-rosenberg-sip-ua-loose-route-00.txt > > Pages : 20 > > Date : 2006-10-13 > > =09 > > A key part of the behavior of the Session Initiation=20 > Protocol (SIP) > > is that SIP proxies rewrite the Request-URI as a request moves > > throughout the network. Over the years, experience has=20 > shown this=20 > > to > > be problematic. It makes it difficult to use Request URI for=20 > > service > > invocation, complicates emergency services, makes it=20 > more complex=20 > > to > > support aliases, and so on. Architecturally, it confounds the > > concepts of address and route. This document proposes to change=20 > > this > > through a new mechanism called UA loose routing. > >=20 > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > se-route-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-rosenberg-sip-ua-loose-route-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt". > > =09 > > 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=20 > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=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 Mon Oct 16 17:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZa9j-0000yz-0r; Mon, 16 Oct 2006 17:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZa9g-0000wJ-SD for sip@ietf.org; Mon, 16 Oct 2006 17:37:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZa9c-0007hM-FP for sip@ietf.org; Mon, 16 Oct 2006 17:37:52 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2006 14:37:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GLbl5L030333; Mon, 16 Oct 2006 14:37:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9GLblin009971; Mon, 16 Oct 2006 14:37:47 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Oct 2006 14:37:47 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 14:37:47 -0700 Message-ID: <4533FBAA.40506@cisco.com> Date: Mon, 16 Oct 2006 17:37:46 -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] I-D on handling large UDP responses References: <4522AFC5.10306@lucent.com> In-Reply-To: <4522AFC5.10306@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 21:37:47.0592 (UTC) FILETIME=[5294DC80:01C6F16B] DKIM-Signature: a=rsa-sha1; q=dns; l=2414; t=1161034668; x=1161898668; c=relaxed/simple; s=sjdkim4002; 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=20on=20handling=20large=20UDP=20responses; X=v=3Dcisco.com=3B=20h=3D/YBF57zo+3Xiigs44TsL/r8oNhY=3D; b=STIPUvtap3hTaf48YhFAHgnAA3MaMKMyv8sfDPiylQd09Q/Q8IMW2oYMnXHi1DfRSMYdLcTQ wmtv7fqjUMItZWlhnZWmfijOgQhK1nvwLzxEi09xVfu5Nk3EXYrOz3H5; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 startign on this problem, Vijay. I understand how the mechanism can diagnose the problem, but I don't see how it can fix it. In particular, when the UAC gets a 140 or 141, and then the transaction times out, the document says it should retry with congestion controlled transport. Well, that would work on the first hop. But nothing in the request would tell the proxy NOT to switch back to UDP. Unless you use sips, and thats assuming its implemented AND assuming its over TLS and all of that... Another problem with the mechanism you have proposed is the long delays involved in waiting for the transaction to timeout. You have discarded the 4xx case, and I think it has merit. You are correct that it may result in false positives - but so what? There are no increases in call setup delays (to me, a worse result). And its reliable. It might help solve this problem above if the 4xx response contains a URI that reaches the resource that wanted to send the error response, but has a DNS entry only for TCP (like a TCP-only GRUU for a UAS). The client also retries with TCP. In the trapezoid model this would at least get you TCP all the way to the terminating proxy. In configurations with many more than that, you do still have the same problem of no way of explicitly requesting TCP. We can solve that with a Proxy-Require I suppose, though we're talking about a proxy upgrade at each hop. -Jonathan R. Vijay K. Gurbani wrote: > Folks: An I-D on handling large UDP response has just been > submitted to the I-D editor. Until it appears in the archives, a > copy can be obtained from: > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/large-udp-response/draft-gurbani-sip-large-udp-response-00.html > > > The draft suggests the use of 1xx-class responses to solve this > problem. > > Please look at the draft and provide comments and/or concerns. > > Thank you. > > - 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 Mon Oct 16 17:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIR-0004HX-RN; Mon, 16 Oct 2006 17:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIR-0004HS-Ax for sip@ietf.org; Mon, 16 Oct 2006 17:46:55 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaIP-0000I8-Vn for sip@ietf.org; Mon, 16 Oct 2006 17:46:55 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9GL3tH20168; Mon, 16 Oct 2006 15:03:55 -0600 Message-ID: <4533F3BA.6000709@ntt-at.com> Date: Mon, 16 Oct 2006 14:03:54 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value References: <45323D98.3050300@gmx.net> In-Reply-To: <45323D98.3050300@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hannes; I have been evaluating the current SIP-SAML profile and for any information that may be used by intermediaries for routing purposes, it may be better to include the SAML assertion by value. SAML can be included in the message body, but that would require UAC to be SAML aware which might not be a reasonable as it adds a lot of load to UAC to support SAML, thus to reduce the complexity, adding it to the SIP header may be a reasonable approach.(Despite the message size implosion etc., I do think there is some benefits, as have been discussed on GEOPRIV on a similar context for location information). But before I go on, trait-authz requirement with MUST strength says that the solution MUST provide a way to prevent unauthorized parties from viewing the contents, which would not hold true if we include the SAML assertion in the header. REQ 11. from RFC4484(trait-authz) " The mechanism MUST provide a way of preventing unauthorized parties (either intermediaries or endpoints) from viewing the contents of assertions." I personally think that the justification for the inclusion of the SAML assertion in the header really depends on what values will be carried in SAML assertion. If the sender or the originating domains see no threat in sharing the information with the rest of the world(say cpc values?), I think it is okay to set the assertion in the header thereby all the entities can see the assertion along the signaling path. If not current SIP-profile should be used to make sure further authentication of the party requesting the SAML can be provided to make sure the assertion is not given to an unwanted parties. Regards Shida Hannes Tschofenig wrote: > Hi all, > > we had some discussions about a SIP proxy adding a SAML assertion to > the SIP header. See issue#9 at > http://www.tschofenig.priv.at:8080/saml-sip/issue9 > > The SIP Payment draft defines a profile that allows SAML assertions to > be added by the end point. I suggest to consider the SIP Payment > mechanism. I am not so sure whether we should move the content of the > SIP Payment draft into the SIP SAML draft. I would prefer to keep the > functionality of the end host to request SAML assertions in the SIP > Payment draft for now. > > This also refers to issue#10. > http://www.tschofeFrom sip-bounces@ietf.org Mon Oct 16 17:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIR-0004HX-RN; Mon, 16 Oct 2006 17:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIR-0004HS-Ax for sip@ietf.org; Mon, 16 Oct 2006 17:46:55 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaIP-0000I8-Vn for sip@ietf.org; Mon, 16 Oct 2006 17:46:55 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9GL3tH20168; Mon, 16 Oct 2006 15:03:55 -0600 Message-ID: <4533F3BA.6000709@ntt-at.com> Date: Mon, 16 Oct 2006 14:03:54 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value References: <45323D98.3050300@gmx.net> In-Reply-To: <45323D98.3050300@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Hannes; I have been evaluating the current SIP-SAML profile and for any information that may be used by intermediaries for routing purposes, it may be better to include the SAML assertion by value. SAML can be included in the message body, but that would require UAC to be SAML aware which might not be a reasonable as it adds a lot of load to UAC to support SAML, thus to reduce the complexity, adding it to the SIP header may be a reasonable approach.(Despite the message size implosion etc., I do think there is some benefits, as have been discussed on GEOPRIV on a similar context for location information). But before I go on, trait-authz requirement with MUST strength says that the solution MUST provide a way to prevent unauthorized parties from viewing the contents, which would not hold true if we include the SAML assertion in the header. REQ 11. from RFC4484(trait-authz) " The mechanism MUST provide a way of preventing unauthorized parties (either intermediaries or endpoints) from viewing the contents of assertions." I personally think that the justification for the inclusion of the SAML assertion in the header really depends on what values will be carried in SAML assertion. If the sender or the originating domains see no threat in sharing the information with the rest of the world(say cpc values?), I think it is okay to set the assertion in the header thereby all the entities can see the assertion along the signaling path. If not current SIP-profile should be used to make sure further authentication of the party requesting the SAML can be provided to make sure the assertion is not given to an unwanted parties. Regards Shida Hannes Tschofenig wrote: > Hi all, > > we had some discussions about a SIP proxy adding a SAML assertion to > the SIP header. See issue#9 at > http://www.tschofenig.priv.at:8080/saml-sip/issue9 > > The SIP Payment draft defines a profile that allows SAML assertions to > be added by the end point. I suggest to consider the SIP Payment > mechanism. I am not so sure whether we should move the content of the > SIP Payment draft into the SIP SAML draft. I would prefer to keep the > functionality of the end host to request SAML assertions in the SIP > Payment draft for now. > > This also refers to issue#10. > http://www.tschofenig.priv.at:8080/saml-sip/issue10 > > Suggestions? > > Ciao > Hannes > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 16 17:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIP-0004HF-5f; Mon, 16 Oct 2006 17:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIO-0004H7-5J for sip@ietf.org; Mon, 16 Oct 2006 17:46:52 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaIL-0000I8-R9 for sip@ietf.org; Mon, 16 Oct 2006 17:46:52 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9GKnQd12379; Mon, 16 Oct 2006 14:49:26 -0600 Message-ID: <4533F056.9020506@ntt-at.com> Date: Mon, 16 Oct 2006 13:49:26 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Sip] SIP SAML: Issue 1 - Multiple SAML Assertions References: <45323F1B.6050308@gmx.net> In-Reply-To: <45323F1B.6050308@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes Tschofenig wrote: > Hi all, > > Shida raised issue#1 (see > http://www.tschofenig.priv.at:8080/saml-sip/issue1 > ) where he points to the need to carry multiple references to SAML > assertions in a single SIP message. > > I think we should support this functionality based on Shida's usage > scenario. > > Objections? > > Ciao > Hannes > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > Hi Hannes; Just reposting the question I posted on the SIP-SAML ML. What to do if we want to embed more than one SAML document? As far as I understand identity header doesn't allow multiple URIs to be added so if there is a need to include more than one SAML document(one by the corporate network that allows the partner company to allocate resource once the call is reached and another one possibly provided by the service provider which has all the charging information such as SIPPING-PAY to actually make the call go through.. This may be an exaggerated example.. and I don't know how much needs for this really exists but as the trait-authz requirements does mention that the solution(SAML profile) SHOULD provide means to include multiple assertions, I think we should carefully study the possible use-cases. Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW dnig.com:8080/saml-sip/issue10 > > Suggestions? > > Ciao > Hannes > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 16 17:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIP-0004HF-5f; Mon, 16 Oct 2006 17:46:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaIO-0004H7-5J for sip@ietf.org; Mon, 16 Oct 2006 17:46:52 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaIL-0000I8-R9 for sip@ietf.org; Mon, 16 Oct 2006 17:46:52 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9GKnQd12379; Mon, 16 Oct 2006 14:49:26 -0600 Message-ID: <4533F056.9020506@ntt-at.com> Date: Mon, 16 Oct 2006 13:49:26 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Sip] SIP SAML: Issue 1 - Multiple SAML Assertions References: <45323F1B.6050308@gmx.net> In-Reply-To: <45323F1B.6050308@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hannes Tschofenig wrote: > Hi all, > > Shida raised issue#1 (see > http://www.tschofenig.priv.at:8080/saml-sip/issue1 > ) where he points to the need to carry multiple references to SAML > assertions in a single SIP message. > > I think we should support this functionality based on Shida's usage > scenario. > > Objections? > > Ciao > Hannes > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > Hi Hannes; Just reposting the question I posted on the SIP-SAML ML. What to do if we want to embed more than one SAML document? As far as I understand identity header doesn't allow multiple URIs to be added so if there is a need to include more than one SAML document(one by the corporate network that allows the partner company to allocate resource once the call is reached and another one possibly provided by the service provider which has all the charging information such as SIPPING-PAY to actually make the call go through.. This may be an exaggerated example.. and I don't know how much needs for this really exists but as the trait-authz requirements does mention that the solution(SAML profile) SHOULD provide means to include multiple assertions, I think we should carefully study the possible use-cases. Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip evelopment of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 18:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaou-0006i3-Pz; Mon, 16 Oct 2006 18:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZanM-0005mx-Ai for sip@ietf.org; Mon, 16 Oct 2006 18:18:52 -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 1GZac4-00024U-Lx for sip@ietf.org; Mon, 16 Oct 2006 18:07:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2006 15:07:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GM7BRA008523; Mon, 16 Oct 2006 15:07:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9GM79WC007648; Mon, 16 Oct 2006 15:07:09 -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); Mon, 16 Oct 2006 15:07:07 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:07:07 -0700 Message-ID: <4534028A.4020501@cisco.com> Date: Mon, 16 Oct 2006 18:07:06 -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: Dean Willis Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 References: <445B5F21.90909@cisco.com> <6290D568-9F19-4CAE-9F1B-40BD19FBEE63@softarmor.com> In-Reply-To: <6290D568-9F19-4CAE-9F1B-40BD19FBEE63@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 22:07:07.0365 (UTC) FILETIME=[6B7CE950:01C6F16F] DKIM-Signature: a=rsa-sha1; q=dns; l=1674; t=1161036431; x=1161900431; 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]=20draft-rosenberg-sip-route-construct-01; X=v=3Dcisco.com=3B=20h=3DKSoygeg6fvYtJS0F65YvUNhkXcg=3D; b=Hatuqd6KbWQ3mfFIFOJcknLmzta2iqQa52/5D/YFeORkQnY2gwjKlLS5ksAJfZbx3ZJsJ006 pzY6GTymAxt0n/mJxR7MUv8t5guOUdXRD+2PYka/J7beyu5QgoFy+gKy; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP IETF , Paul Kyzivat , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 dont think its crazy dean. Its more or less what I'm planning on putting in the revision to route-construct. -Jonathan R. Dean Willis wrote: > > On May 5, 2006, at 9:20 AM, Paul Kyzivat wrote: > > >> >> Section 4 says that the s-r is associated with each registered >> contact rather than the AOR. By that, I guess you mean that if the >> register contains contacts X and Y, and the register response >> contains contacts X,Y,Z then the s-r applies to X and Y. Then what >> about a polling register that contains no contacts? Either it >> contains a s-r that applies to nothing, or else it shouldn't contain >> a s-r at all. I guess this is implied, but might be worth pointing out. >> > > This is exactly why we made S-R and Path apply to the AOR and not the > contact originally. > > I wanted to change things such that the registrar stores and returns a > contact-route instead of just a contact, but folks thought I was > crazier than usual. > > -- > 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 > -- 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 Mon Oct 16 18:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaqN-0007OH-JW; Mon, 16 Oct 2006 18:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZanN-0005jM-Sb for sip@ietf.org; Mon, 16 Oct 2006 18:18:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZaas-0001yp-Jk for sip@ietf.org; Mon, 16 Oct 2006 18:06:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 15:05:58 -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 k9GM5vd0032738; Mon, 16 Oct 2006 15:05:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9GM5vAo023243; Mon, 16 Oct 2006 15:05:57 -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); Mon, 16 Oct 2006 15:05:57 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:05:57 -0700 Message-ID: <45340243.3080209@cisco.com> Date: Mon, 16 Oct 2006 18:05:55 -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: Paul Kyzivat Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 References: <445B5F21.90909@cisco.com> In-Reply-To: <445B5F21.90909@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 22:05:57.0286 (UTC) FILETIME=[41B7B460:01C6F16F] DKIM-Signature: a=rsa-sha1; q=dns; l=6704; t=1161036357; x=1161900357; c=relaxed/simple; s=sjdkim2002; 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-rosenberg-sip-route-construct-01; X=v=3Dcisco.com=3B=20h=3DKSoygeg6fvYtJS0F65YvUNhkXcg=3D; b=DnoSEop19FpoAqJjqOAYowQFWfalhXdUeuvCtErquo2vsU9ygKvwQqJTBSFxrgYkms0kzuxv M1bc9pJtID9ClmggnL2xmnITHAG84lY4+9cRZuj8Bt/W3s/iAvDu5hNT; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: SIP IETF , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Wow - its been like 5 months since you sent this. I am now revising route-construct again, since its a key part of this mid-dialog failover mechanism for SIP-outbound, in addition to being needed for other reasons. So, thanks for the comments, and some responses inline. For anyone else interested in this stuff, the draft has actually expired. It can be picked up on my website: http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-01.txt Paul Kyzivat wrote: > Jonathan, > > I think we need this badly. It is clearly a complex issue. A few > comments and questions about the new version: > > Section 4 says that the s-r is associated with each registered contact > rather than the AOR. By that, I guess you mean that if the register > contains contacts X and Y, and the register response contains contacts > X,Y,Z then the s-r applies to X and Y. Actually what I'd like to say is that this mechanism only works when REGISTER has one contact. Realistically speaking, we are moving more and more towards the model where your REGISTER message is registering where you came from (sip outbound). If you are doing a third party register (and there are almost always better ways to accomplish a goal than that), or you are doing a polling register (for which there is little need anymore) you just don't get this feature. Then what about a polling > register that contains no contacts? Either it contains a s-r that > applies to nothing, or else it shouldn't contain a s-r at all. I guess > this is implied, but might be worth pointing out. No S-R. I'd also go so far as to argue that, even if there are multpple UA, with this service route extension, the registrar just returns YOUR contact. It avoids the pain of looking through the contacts to find your own, and you don't need them anyway. Again this is along the lines of where register is going with sip-outbound. > > Regarding doing things with domains under the control of the proxy: it > turns out to be interesting that none of the IMS elements seem to know > which domains they control. All they really know is which URIs get > matched in the HSS. There is also implicit understanding in the sense > that any domains that get routed to one of the elements of the IMS > network via normal routing policies must somehow be controlled by it, > but it will only understand this via the HSS lookup. So any logic of the > form: "do XYZ to a URI if the domain of the URI is one you control" is > problematic for IMS. Hmm, I added these words for IMS in fact. Somehow I recall that the S-CSCF could insert additional service-routes besides just the S-CSCF. If this is not true its even easier. I would much prefer the spec just basically say to invert Path and thats it. > > I like the use of the lr parameter in a contact to decide whether to > rewrite the aor with the registered contact. clever. Thanks. This is now fully expanded upon in: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt and I will remove it from the next revision in service route. > > Section 5.4 says that a client (proxy or not) receiving a 305 with > non-zero response-target should not recurse on it. So what should a UAC > do in this case? Seems like this is equivalent to a 500 response. I suppose. I've reconsidered this whole mechanism further and think its WAY too complciated. I was thinking of features like having a home proxy tell a UA to register to a different home proxy using a 305 targeted at the UA. However, there is no real need for that. If you limit recursion to the previous hop, the whole mechanism becomes much simpler. Indeed, the alternative is discussed in the loose-route draft, which is more or less what Jeroen has posted on this old thread (to which I will reply shortly). Include a flag in the Via. Redirect if the topmost Via has the flag, and the recursion is always by that entity. Then, this issue you raise goes away. > > The rules for 305 processing don't mention stateless proxies. It is > possible for a 305 to be targetted to a stateless proxy. But in that > case it won't have the state needed to do the recursion. And of course > it is unclear how the sender of the 305 can tell what element to target > and whether it is stateless or not. Seems like some guidance on how to > select a 305 target is needed. But it is far from clear to me what that > guidance would be. I think the guidance would be that a stateless proxy cannot implement this mechanism. Per above, it would not insert this flag into the topmost Via. > > What should be done about a 305 received during recursion of a prior > 305? The obvious thing would be to start the recursion over with the new > value(s). But there is a potential for looping here. And I don't think > that is covered by 3261. So maybe some new loop prevention logic is > needed here. I think it would recurse again. You are right there could be a loop. Text needs to be added (presumably in loose route since that is where I have put this) that says that you don't recurse toa URI you already recursed to. There would probably also need to be a fixed limit on the total number of recursions done in a transaction. > > I didn't see much mention of routing done independently of the route > headers. E.g. sending to an outbound proxy that is not mentioned in the > route header. In most cases I suppose that should still be ok. But when > done by the UAC it adds confusion to what should then be done when > receiving a 305. In particular if a UAC does this, then its outbound > proxy could never bypass itself using a 305. I guess that behavior could > be deprecated here, but I'm not certain what all the implications of > that are. Hmm good question. My assumption was that the outbound proxy had been in the Route set. If it hadn't, I think the 305 gets processed as if it had been, in which case the 305 would replace it. That needs to be mentioned I think. Again it would go in ua-loose-route since that is where I have put all of this. route-construct will therefore more or less become an update to service-route that also integrates the logic defined in loose-route. -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 Mon Oct 16 18:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZaqr-0007nt-Dd; Mon, 16 Oct 2006 18:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZanJ-0005o7-By for sip@ietf.org; Mon, 16 Oct 2006 18:18:49 -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 1GZade-0002Do-ON for sip@ietf.org; Mon, 16 Oct 2006 18:08:52 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2006 15:08:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9GM8omB027318; Mon, 16 Oct 2006 15:08:50 -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 k9GM8oAo026093; Mon, 16 Oct 2006 15:08:50 -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); Mon, 16 Oct 2006 15:08:49 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:08:49 -0700 Message-ID: <453402F0.1010203@cisco.com> Date: Mon, 16 Oct 2006 18:08:48 -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: Jeroen van Bemmel Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 References: <445B5F21.90909@cisco.com> <000801c6709f$e83c1340$31713b51@BEMBUSTER> In-Reply-To: <000801c6709f$e83c1340$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 22:08:49.0577 (UTC) FILETIME=[A8693990:01C6F16F] DKIM-Signature: a=rsa-sha1; q=dns; l=1540; t=1161036530; x=1161900530; c=relaxed/simple; s=sjdkim3002; 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-rosenberg-sip-route-construct-01; X=v=3Dcisco.com=3B=20h=3DKSoygeg6fvYtJS0F65YvUNhkXcg=3D; b=jr3ZcbKCFsDNpTUMv2rRjE+eKs8mFO4iNVGkGzsIDCamgjvH5/OXKxBIjNsQBnTzQbSGKkkX Zm41FHFU1Z+2tsimcISqXhurUEK/UcfA+Sac75PH2FqSecDCO0tvtzX4; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP IETF , Paul Kyzivat , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Jeroen. Sorry they are super-super late. I put this work aside for a long while. inline. Jeroen van Bemmel wrote: > Jonathan, > > The 305 re-routing mechanism in section 4 seems more complex than it > needs to be, and adds overhead to all requests. How about the following: Way to complex in fact. More below. > > 1. Each compliant proxy adds a new 'rt' flag to its Via header Yes I like that and this is what I put into the UA loose route document. > 2. The proxy / UAS that sends the 305 counts how many via's contain this > flag, starting from the top, and inserts this as a count into the > Redirect-Target header > 3. 305 is forwarded upstream, each proxy decrements as currently > specified, when it becomes 0 the proxy recurses I'm thinking, why even be this complicated. If you limit the 3xx to be to the previous hop only, things are much simpler. It also eliminates all these issues of dealing with SBCs and other nasties that remove Via headers. > > If local policy says that downstream elements are not allowed to > redirect upstream, a proxy would remove the 'rt' flag from the received > top via Right. -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 Mon Oct 16 18:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZarJ-0000ik-Gh; Mon, 16 Oct 2006 18:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZarI-0000fL-RB for sip@ietf.org; Mon, 16 Oct 2006 18:22:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZarH-0004No-Cn for sip@ietf.org; Mon, 16 Oct 2006 18:22:56 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 15:22:55 -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 k9GMMs0t028636; Mon, 16 Oct 2006 15:22:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9GMMsW4022917; Mon, 16 Oct 2006 15:22:54 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Oct 2006 15:22:54 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:22:54 -0700 Message-ID: <4534063C.4020302@cisco.com> Date: Mon, 16 Oct 2006 18:22:52 -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 References: <1ECE0EB50388174790F9694F77522CCF0D8A90AF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D8A90AF@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 22:22:54.0299 (UTC) FILETIME=[9FE792B0:01C6F171] DKIM-Signature: a=rsa-sha1; q=dns; l=3769; t=1161037374; x=1161901374; c=relaxed/simple; s=sjdkim4002; 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=20I-D=20ACTION=3Adraft-rosenberg-sip-ua-loose-route-00.txt; X=v=3Dcisco.com=3B=20h=3DZTZo7LbmwUJlR7zoBTlr/rV/HxU=3D; b=tMRlEq+IQ8Ndfe1gh0mEFs+IkeZznOJ18GAr0QYREpWYLQuiyK0VLj6EBif7EdYTCTiTcErX 2YA1IRz6ik39P+tQsU6wBtb20uR5ka3Q+1EdjS2hTL0Gwi8ip/Jmt+Xa; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: sip@ietf.org Subject: [Sip] Re: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.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 Thanks for the comments Francois. Responses inline. Francois Audet wrote: > Hi Jonathan, > > Good job with this draft. Here are some comments on it. > > There is one case not mentioned in this draft that I think should be > discussed. It is somewhat similar to your 1-800 number. > > It is very common in PSTN to be reachable by more than one phone > numbers. > > Of particular importance is the case of Enterprise users who typically > have > both an E.164 Public number and one or more Private corporate numbers > (typically, a "long" corporate-wide number valid in > phone-context=expample.com > and also a "short" number valid in a specific location such as > phone-context= > santaclara.example.com). Similar arrangements also exist in Public > networks > (like your 1-800 example). The difference is that in Enterprises, it is > almost > always the case that multiple numbers are supported. Right. I am familiar with this problem. There are actually a number issues in supporting it.... > > Seems to me this should be discussed in the draft. This draft can help answer the question of knowing by which of these you were reached, and it would appear in the R-URI. I think thats more or less the aliasing problem in Setion 2.1, no? I can certainly mention enterprise as another case. > > Now, there is some additional complexity to consider here. Typically, a > SIP UA > (such as a SIP phone) will be configured with it's AOR consisting of a > username > and domain name (sip:user1@example.com). It only "knows" of one of that > identity. > That identity could be an alphanumeric username, or it could even look > like a phone > number (typical with low-end SIP phone installations). > > The problem is that it is unlikely that these devices will "know" all > the possible > phone numbers assigned to them as this is normally centrally configured. > And a phone > will not normally accept arbitrary requests to URIs it doesn't > understand (otherwise, > a device supporting multiple users wouldn't know which line > appearance/user the request > is targetted to). It could also be bad for SPIT. You get little protection by checking if you know the R-URI. Spammers will just use that URI. What you want is to only accept requests that your home proxy decided ought to be delivered to you. Thats done with things TLS to your proxy, and only accepting inbound requests over that connection. > > I guess the solution to this would be for such an endpoint to rely on > the Route header for > such purpose instead of the Request-URI. This was probably your > intention, but maybe making > it explicit would be useful. I hadn't considered this case. I had in mind at least the IMS model where the UA does actually know its aliases. But anyway I think there is a difference between how to authorize accepting a request and how to know to where the request was sent. Per above receiving a request over the TLS connection to your proxy is a much better authorization tool than examining the topmost Route header field. > > Another suggestion is to add a URI parameter to the example. One of the > main benefits of > this draft is to preserve URI parameters potentially useful for the > target (as we discussed > on the mailing list). A mention of this in the draft would be quite > useful. OK, will do. 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 Mon Oct 16 18:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZawM-0003Sn-Ou; Mon, 16 Oct 2006 18:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZawK-0003Sf-S7 for sip@ietf.org; Mon, 16 Oct 2006 18:28:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZawJ-0005Af-GH for sip@ietf.org; Mon, 16 Oct 2006 18:28:08 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 15:28:07 -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 k9GMS7DE005149; Mon, 16 Oct 2006 15:28:07 -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 k9GMS6Ao015880; Mon, 16 Oct 2006 15:28:06 -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); Mon, 16 Oct 2006 15:28:06 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 15:28:05 -0700 Message-ID: <45340774.9070806@cisco.com> Date: Mon, 16 Oct 2006 18:28:04 -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: Brian Stucker Subject: Re: [Sip] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt References: <6FC4416DDE56C44DA0AEE67BC7CA437110F1F889@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110F1F889@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2006 22:28:06.0084 (UTC) FILETIME=[59BE3040:01C6F172] DKIM-Signature: a=rsa-sha1; q=dns; l=3022; t=1161037687; x=1161901687; 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]=20RE=3A=20I-D=20ACTION=3Adraft-rosenberg-sip-ua-loose-rout e-00.txt; X=v=3Dcisco.com=3B=20h=3DGVGvnd2tkhOdEmO6Nt2fkphRyOU=3D; b=MLhDPtQQQqG9tT0ZcrnK9EXHa5p6lDdZWribU3SWgXoHG37fj6cEEiMfCthivLw1V7/tG3bf zp3vUi27Pp6eh5FJpIWiWgtJDRIF7ezOjPGP3RTN0tpFeAHonnmpOnx/; Authentication-Results: sj-dkim-1.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@ietf.org, 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 Brian Stucker wrote: > Jonathan, > > Thanks for chronicling the discussion into a draft. > > Just to build from Francois' comments (still reading through the entire > draft)... > > If the UA is to look at the Route header to get the identity at which it > should accept the the request because the Request-URI could be who knows > what, isn't this confabulating the purposes of the two headers? We'd be > using a routing header for identity purposes. See my response to Francois; I don't think thats what you want. If the UA wants to authorize an incoming request it uses a real security technique. That said, I don't actually see anything wrong with using a Route haeder field for determining how to process a request. Thats already what proxies do and have been doing since the dawn of SIP. > >>From section 4.2, you mention that the exact purpose of the Route header > is to indicate the next hop of the request, but now it would also have > to be the identity at that next hop that you're wishing to be contacted > as well. This assumes, of course, that Francois' concern about the > reliability of the Request-URI value (when you take into account limited > UA behavior) pans out (which I think it will). I'm not sure I follow. With proxies, the Route header field identifies the next hop. WIth the introduction of loose routing in RFC3261, when received at that hop, it examines the URI, checks that it is 'its own', and proceeds if it is. I am merely extending that exact processing to UA. That doesn't mean that Route becomes an identity header akin to P-A-ID. It would mean that a UA would check that the Route haeder field matches its registered contact, if it wants. Though its not clear to me what security benefits are derived from that check in the absence of tls I must say. > > Thoughts? > > Also, the comment at the bottom of section 4.2 about H-I seemed > prejudicial/self-conflicting: > > "Thirdly, the history specification is fairly complex and has seen > limited industry adoption. This should never be a reason to not use a > mechanism when its the right choice, but its a consideration that > warrants mentioning." > > If something should never be a reason to exclude a mechanism then why is > it a consideration? I was putting all of the cards on the table. I'm happy to remove this since claerly I was iffy on this as a reason myself. I have other concerns about history-info and they are there also in teh document. Note that I'm not in fact proposing to get rid of H-I at all. I'm merely trying to frame when it is used (retargeting) vs. when its not (routing). -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 Mon Oct 16 19:24:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZbld-0000e5-BN; Mon, 16 Oct 2006 19:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZblb-0000dt-8v for sip@ietf.org; Mon, 16 Oct 2006 19:21:07 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZblY-0002ex-R6 for sip@ietf.org; Mon, 16 Oct 2006 19:21:07 -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 k9GNL1H26877; Mon, 16 Oct 2006 19:21:01 -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] Re: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Date: Mon, 16 Oct 2006 18:20:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0D91C11D@zrc2hxm0.corp.nortel.com> In-reply-to: <4534063C.4020302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Thread-Index: AcbxcajTaGPce3dhSwyBRMHAGbvENwABSTJw From: "Francois Audet" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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.=20 See below. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, October 16, 2006 3:23 PM > To: Audet, Francois (SC100:3055) > Cc: sip@ietf.org > Subject: [Sip] Re: I-D=20 > ACTION:draft-rosenberg-sip-ua-loose-route-00.txt >=20 > Thanks for the comments Francois. Responses inline. >=20 > Francois Audet wrote: >=20 > > Hi Jonathan, > >=20 > > Good job with this draft. Here are some comments on it. > >=20 > > There is one case not mentioned in this draft that I think=20 > should be=20 > > discussed. It is somewhat similar to your 1-800 number. > >=20 > > It is very common in PSTN to be reachable by more than one phone=20 > > numbers. > >=20 > > Of particular importance is the case of Enterprise users=20 > who typically=20 > > have both an E.164 Public number and one or more Private corporate=20 > > numbers (typically, a "long" corporate-wide number valid in=20 > > phone-context=3Dexpample.com and also a "short" number valid in a=20 > > specific location such as phone-context=3D santaclara.example.com).=20 > > Similar arrangements also exist in Public networks (like your 1-800=20 > > example). The difference is that in Enterprises, it is=20 > almost always=20 > > the case that multiple numbers are supported. >=20 > Right. I am familiar with this problem. There are actually a=20 > number issues in supporting it.... I'm thinking that your draft actually helps with this problem. > >=20 > > Seems to me this should be discussed in the draft. >=20 > This draft can help answer the question of knowing by which=20 > of these you were reached, and it would appear in the R-URI.=20 > I think thats more or less the aliasing problem in Setion=20 > 2.1, no? I can certainly mention enterprise as another case. Well, maybe I guess. I've never tought of these phone numbers as AOR really, because they are not associated with registration. Phone numbers can result in different devices/users being addressed completely independently of registration. Proxies may have rules that routes calls to +1-555-1212 to different AORs (e.g., agents) based on time of day, load balancing, or any other criteria. Also, I do not expect that the devices themselves would be aware of their own phone numbers. It's something that is managed elsewhere. That's why I tought it was more analogous to your section 2.7 on=20 Freephone numbers. What I'd like to see is either an expansion of section 2.7 to cover phone numbers in general, including enterprise numbering plan as per my example, or maybe a section 2.8 on it. As you prefer.=20 =20 > >=20 > > Now, there is some additional complexity to consider here.=20 > Typically, a > > SIP UA > > (such as a SIP phone) will be configured with it's AOR=20 > consisting of a > > username > > and domain name (sip:user1@example.com). It only "knows" of=20 > one of that > > identity. > > That identity could be an alphanumeric username, or it=20 > could even look > > like a phone > > number (typical with low-end SIP phone installations). > >=20 > > The problem is that it is unlikely that these devices will=20 > "know" all > > the possible > > phone numbers assigned to them as this is normally=20 > centrally configured. > > And a phone > > will not normally accept arbitrary requests to URIs it doesn't > > understand (otherwise, > > a device supporting multiple users wouldn't know which line > > appearance/user the request > > is targetted to). It could also be bad for SPIT. >=20 > You get little protection by checking if you know the R-URI. Spammers=20 > will just use that URI. What you want is to only accept requests that=20 > your home proxy decided ought to be delivered to you. Thats done with=20 > things TLS to your proxy, and only accepting inbound requests=20 > over that=20 > connection. I'm more concerned about the following simple case: - A device has 2 (or more) users logged in (on different line appearances).=20 - When it gets an incoming request, it needs to be able to figure out which of the users the call is destined to. - Because of this, that device can not just "blindly" accept calls to=20 arbitrary AORs that it doesn't understand. With the current procedures, it must look at the Request-URI. With your draft, it would be the Route header instead. Your draft would allow that device to know not only which user the call is destined to, but also how it was addressed. That's one of the reason=20 I like it. > >=20 > > I guess the solution to this would be for such an endpoint=20 > to rely on > > the Route header for > > such purpose instead of the Request-URI. This was probably your > > intention, but maybe making > > it explicit would be useful. >=20 > I hadn't considered this case. I had in mind at least the IMS model=20 > where the UA does actually know its aliases. But anyway I=20 > think there is=20 > a difference between how to authorize accepting a request and how to=20 > know to where the request was sent. Per above receiving a=20 > request over=20 > the TLS connection to your proxy is a much better authorization tool=20 > than examining the topmost Route header field. Well, yes, TLS is much better, I agree, but it doesn't mean that it should be broken. The multi-user terminal is an example. Another one is in the event of a device shutting down without properly=20 un-registering, it is possible that another device would be assigned the old IP address. This could result in calls (or IM) being directed to the wrong device/user. I've seen it... =20 > > Another suggestion is to add a URI parameter to the=20 > example. One of the > > main benefits of > > this draft is to preserve URI parameters potentially useful for the > > target (as we discussed > > on the mailing list). A mention of this in the draft would be quite > > useful. >=20 > OK, will do. Thanks. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 19:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZbtS-0002gd-1p; Mon, 16 Oct 2006 19:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZbtQ-0002Xd-AS for sip@ietf.org; Mon, 16 Oct 2006 19:29:12 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZbtO-0003ll-US for sip@ietf.org; Mon, 16 Oct 2006 19:29:12 -0400 Received: (qmail 25220 invoked by uid 0); 16 Oct 2006 23:30:03 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 Oct 2006 23:30:03 -0000 Message-ID: <00f201c6f17a$d79777d0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <445B5F21.90909@cisco.com> <000801c6709f$e83c1340$31713b51@BEMBUSTER> <453402F0.1010203@cisco.com> Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 Date: Tue, 17 Oct 2006 01:28:52 +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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP IETF , Paul Kyzivat , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> 2. The proxy / UAS that sends the 305 counts how many via's contain >> this flag, starting from the top, and inserts this as a count into >> the Redirect-Target header >> 3. 305 is forwarded upstream, each proxy decrements as currently >> specified, when it becomes 0 the proxy recurses > > I'm thinking, why even be this complicated. If you limit the 3xx to be > to the previous hop only, things are much simpler. It also eliminates > all these issues of dealing with SBCs and other nasties that remove > Via headers. Yes, you could simplify it like that. Still can't avoid to scan the Via headers though, since the previous hop might be a stateless proxy which would not be able to perform the redirect (and hence MUST NOT insert a flag I suppose). So we would have "previous stateful hop that supports the mechanism". If there is no such hop, 305 should not be sent (as it would probably confuse older clients). 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 Mon Oct 16 21:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdPR-0007Ky-As; Mon, 16 Oct 2006 21:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdPP-0007Kd-HX for sip@ietf.org; Mon, 16 Oct 2006 21:06:19 -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 1GZdP0-0000SG-SE for sip@ietf.org; Mon, 16 Oct 2006 21:06:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2006 18:05:40 -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 k9H15eBP002181; Mon, 16 Oct 2006 18:05:40 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9H15ein002123; Mon, 16 Oct 2006 18:05:40 -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); Mon, 16 Oct 2006 18:05:40 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 18:05:39 -0700 Message-ID: <45342C62.8060807@cisco.com> Date: Mon, 16 Oct 2006 21:05: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: Jeroen van Bemmel Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 References: <445B5F21.90909@cisco.com> <000801c6709f$e83c1340$31713b51@BEMBUSTER> <453402F0.1010203@cisco.com> <00f201c6f17a$d79777d0$0601a8c0@BEMBUSTER> In-Reply-To: <00f201c6f17a$d79777d0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 01:05:40.0066 (UTC) FILETIME=[5CC15C20:01C6F188] DKIM-Signature: a=rsa-sha1; q=dns; l=1675; t=1161047140; x=1161911140; c=relaxed/simple; s=sjdkim2002; 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-rosenberg-sip-route-construct-01; X=v=3Dcisco.com=3B=20h=3DKSoygeg6fvYtJS0F65YvUNhkXcg=3D; b=IHS/1JzIfu5bsmcKALZOaJh86Ae4LnZ7Nh32Fsh2gsowMTEq9fPsK9+nv8cc1db7pwYyrp37 k4YF8YGB5QyXF1cXG7eersD8ekI/dPdmCrHrFlacW0a2DE8Pd7IDrE0Q; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: SIP IETF , Paul Kyzivat , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 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. Jeroen van Bemmel wrote: > >>> 2. The proxy / UAS that sends the 305 counts how many via's contain >>> this flag, starting from the top, and inserts this as a count into >>> the Redirect-Target header >>> 3. 305 is forwarded upstream, each proxy decrements as currently >>> specified, when it becomes 0 the proxy recurses >> >> >> I'm thinking, why even be this complicated. If you limit the 3xx to be >> to the previous hop only, things are much simpler. It also eliminates >> all these issues of dealing with SBCs and other nasties that remove >> Via headers. > > > Yes, you could simplify it like that. Still can't avoid to scan the Via > headers though, since the previous hop might be a stateless proxy which > would not be able to perform the redirect (and hence MUST NOT insert a > flag I suppose). So we would have "previous stateful hop that supports > the mechanism". If there is no such hop, 305 should not be sent (as it > would probably confuse older clients). You don't need to scan the Via list. If the previous hop is a stateless proxy and didn't insert the flag (which it won't) you can't do the 305. You would never need to look beyond the previous hop since a redirect would have to be consumed by the previous hop, or you wouldn't be allowed to send it. 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 Mon Oct 16 21:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdSi-0001Nc-FZ; Mon, 16 Oct 2006 21:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZdSg-0001NK-U0 for sip@ietf.org; Mon, 16 Oct 2006 21:09:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZdSe-0001Ns-ET for sip@ietf.org; Mon, 16 Oct 2006 21:09:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2006 18:09:40 -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 k9H19eP0012447; Mon, 16 Oct 2006 18:09:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9H19dAo018658; Mon, 16 Oct 2006 18:09:39 -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); Mon, 16 Oct 2006 18:09:39 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 18:09:39 -0700 Message-ID: <45342D52.50907@cisco.com> Date: Mon, 16 Oct 2006 21:09: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: Francois Audet Subject: Re: [Sip] Re: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt References: <1ECE0EB50388174790F9694F77522CCF0D91C11D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0D91C11D@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 01:09:39.0209 (UTC) FILETIME=[EB4BAF90:01C6F188] DKIM-Signature: a=rsa-sha1; q=dns; l=3835; t=1161047380; x=1161911380; 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]=20Re=3A=20I-D=20ACTION=3Adraft-rosenberg-sip-ua-loose-rout e-00.txt; X=v=3Dcisco.com=3B=20h=3DP5c0txsxn7F1qsnAIgi4r0LQU/4=3D; b=Z8VTVQZdxtCoJAXkc5zXu67xT1hQ2bKSaqR6bEAAKcZgdPymylwLJSEmiysFuHm2bGUecLVU 1d2d5mVoLgWAhDO9RtoefzaLAl90ozHoRFYrym+O3a4Gpyz0bgLXih/a; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: >>This draft can help answer the question of knowing by which >>of these you were reached, and it would appear in the R-URI. >>I think thats more or less the aliasing problem in Setion >>2.1, no? I can certainly mention enterprise as another case. > > > Well, maybe I guess. I've never tought of these phone numbers > as AOR really, because they are not associated with registration. Fair enough, but they are AOR in that they are identities by which someone can reach me. Aliases for the AOR would be another way to think about them. > > Phone numbers can result in different devices/users being addressed > completely independently of registration. Proxies may have rules > that routes calls to +1-555-1212 to different AORs (e.g., agents) based > on time of day, load balancing, or any other criteria. > > Also, I do not expect that the devices themselves would be aware of > their > own phone numbers. It's something that is managed elsewhere. Again it depends on the system in use. > > That's why I tought it was more analogous to your section 2.7 on > Freephone numbers. > > What I'd like to see is either an expansion of section 2.7 to cover > phone numbers in general, including enterprise numbering plan as per my > example, or maybe a section 2.8 on it. As you prefer. OK, I'll work something in. >>You get little protection by checking if you know the R-URI. Spammers >>will just use that URI. What you want is to only accept requests that >>your home proxy decided ought to be delivered to you. Thats done with >>things TLS to your proxy, and only accepting inbound requests >>over that >>connection. > > > I'm more concerned about the following simple case: > > - A device has 2 (or more) users logged in (on different line > appearances). > > - When it gets an incoming request, it needs to be able to figure out > which of the users the call is destined to. > > - Because of this, that device can not just "blindly" accept calls to > arbitrary AORs that it doesn't understand. With the current > procedures, it > must look at the Request-URI. With your draft, it would be the Route > header > instead. Well it'd be both in this case. Presumably each user has a different AOR so those appaer in the R-URI. > Your draft would allow that device to know not only which > user the > call is destined to, but also how it was addressed. That's one of the > reason > I like it. Right, it gives you both pieces of information, so you can use whichever you like. >>I hadn't considered this case. I had in mind at least the IMS model >>where the UA does actually know its aliases. But anyway I >>think there is >>a difference between how to authorize accepting a request and how to >>know to where the request was sent. Per above receiving a >>request over >>the TLS connection to your proxy is a much better authorization tool >>than examining the topmost Route header field. > > > Well, yes, TLS is much better, I agree, but it doesn't mean that it > should > be broken. > > The multi-user terminal is an example. > > Another one is in the event of a device shutting down without properly > un-registering, it is possible that another device would be assigned the > old IP address. This could result in calls (or IM) being directed to the > wrong device/user. I've seen it... OK, fair point. -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 Mon Oct 16 22:06:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeIZ-00035D-0i; Mon, 16 Oct 2006 22:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeIX-00033S-7Q for sip@ietf.org; Mon, 16 Oct 2006 22:03:17 -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 1GZeIT-00018w-PM for sip@ietf.org; Mon, 16 Oct 2006 22:03:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2006 19:03:13 -0700 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 k9H23Dx4010922 for ; Mon, 16 Oct 2006 19:03:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9H23DW4025804 for ; Mon, 16 Oct 2006 19:03:13 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 Oct 2006 19:03:13 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 19:03:12 -0700 Message-ID: <453439DF.3000507@cisco.com> Date: Mon, 16 Oct 2006 22:03: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 02:03:12.0808 (UTC) FILETIME=[66BFFA80:01C6F190] DKIM-Signature: a=rsa-sha1; q=dns; l=3449; t=1161050593; x=1161914593; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:identity-coexistence=3A=20the=20value=20of=20signatures; X=v=3Dcisco.com=3B=20h=3DX+Srmf8hXz2eXAvmHegV1329JY0=3D; b=dgrbgrp8wsunRNVtpfrGefiuQz2iZAsuXn5bbtOC0kzVTBHJFi1QpZ/jp9WlQZBOO0g+/mKo tQXk4jQKiLeRU+jyOff8t7vkcIMxlHWFSG7yj3rWULHSDdEjhKU0JSmO; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Sip] identity-coexistence: the value of signatures X-BeenThere: sip@ietf.org X-Mailman-Version: 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 on my long list of drafts to revise before the deadline, the identity-coexistence draft: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexistence-00.txt There was a good thread back in August on this topic, driven off on some comments by Cullen. Here is the thread URL if you are interested: http://www1.ietf.org/mail-archive/web/sip/current/msg14996.html There were a few issues in this thread, but the biggest byfar is the issue of what to do in transit domains that have b2bua which modify the Contact or SDP, invalidating the signature. Consider, for example, a chain of domains A->B->C->D. The caller is in A.com and the called party in B.com. The From header field of sip:caller@A.com is signed by a proxy in A.com. It goes through two transit providers B and C prior to reaching D. If a b2bua in B or C are B2bUA the signature is invalidated. One proposal, that I think Cullen was arguing for unless I am mistaken, was that if B modifies the message it resigns using its own cert. C receives this, and if it trusts B it would resign with its cert too. Then it arrives at D, who of course trusts A and so resigns it with its own cert. THen, the idea is that teh UAS is configured to accept a signature even if the domain in the cert doesn't match the From domain, if the cert is from a configured list of good domains, which typically is just one domain - its own, D.com. Hadriel posted in reply that if you do this, why bother with SIP identity? May as well use P-Asserted-ID since you are back to transitive trust. And indeed I have to agree with this. The reason I felt that SIP identity is superior to P-Asserted-ID is that I, in the terminating domina, know exactly who the originating domain was, and I could use that information to plug it into black/white lists, authorization rules, and so on, to decide whether to accept the call. The canonical use case I have for this is a call from spammers.com, who gets service from their provider littlecountry.com, who gets service from biginterconnectprovider.com, which connects to my own provider, myprovider.com. Though there IS in fact transitive trust at each hop, the net value of P-Asserted-ID is nil here. The reason is that the value of P-Asserted-ID is equal to the trustworthiness of the LEAST trustworthy provider in the chain. In a transit situation, this exponentially approaches zero. However with SIP identity, I can directly determine that this is coming from spammers.com and look them up in sipspamhaus.org and reject their calls as a matter of local policy. So if you emloy resigning at each transit hop, you will basically eliminate all of the benefit that SIP identity brings to the table, and I think thats bad. Consequently, unless the transit is something like an anonymizing provider (and there are legitimate use cases for it), which purposefully masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK THROUGH TRANSIT B2BUA*. That is the cost of the increased security we get. 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 Mon Oct 16 23:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZf92-0004K7-46; Mon, 16 Oct 2006 22:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZf90-0004K2-3i for sip@ietf.org; Mon, 16 Oct 2006 22:57:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZf8y-0003LL-RA for sip@ietf.org; Mon, 16 Oct 2006 22:57:30 -0400 Received: from [192.168.1.106] (adsl-68-94-28-25.dsl.rcsntx.swbell.net [68.94.28.25]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k9H2vNNH088688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Oct 2006 21:57:24 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4530B11A.2080302@ericsson.com> References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 Date: Mon, 16 Oct 2006 21:57:06 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.28.25 is authenticated by a trusted mechanism) X-Spam-Score: 2.1 (++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "sip@ietf.org" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 14, 2006, at 4:42 AM, Gonzalo Camarillo wrote: [snip] > > Therefore, an alternative solution (which was discussed in the > past) to > the REFER approach would be to define the Trigger-Consent header field > so that it contains the recipient URI of the translation and a SIP > URI. > The recipient would send a PUBLISH request (instead of a REFER) to > that > URI to trigger a new MESSAGE request with a permission document. > > The reason why the Trigger-Consent header field needs to carry the > recipient URI of the translation is because a request can go through > more than one translation before reaching the recipient. > >> Technical comment on Trigger-Consent: the ABNF in section 5.11 allows >> multiple instances of this header. Is this desired? > > I answered this above. > > If folks prefer this PUBLISH-based solution over the REFER-based > solution I can edit the draft accordingly. > I am reviewing in a separate email, but I will state here that I do like the publish approach better than the refer approach--but why use the additional step of the Trigger-Consent? Why not just send the "deny" URL in each translated request, and let the recipient skip the step of requesting a new permissions document just to get the deny URL? (I'm sure there is a very good reason that we have already discussed.) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 23:42:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfoj-00051f-G8; Mon, 16 Oct 2006 23:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfoh-00051Z-MM for sip@ietf.org; Mon, 16 Oct 2006 23:40:35 -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 1GZfoh-0005e4-2b for sip@ietf.org; Mon, 16 Oct 2006 23:40:35 -0400 Received: from [192.168.1.106] (adsl-68-94-28-25.dsl.rcsntx.swbell.net [68.94.28.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9H3ePGv034545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Oct 2006 22:40:30 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Mon, 16 Oct 2006 22:40:09 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.2 (++) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: Sip List Subject: [Sip] WGLC comments for draft-ietf-sip-consent-framework-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 draft-ietf-sip-consent-framework-00. General: I know this has been discussed, but I have some concerns about the fact that permissions are not soft-state. This seems contrary to one of the most basic SIP design principles. I will address some specific issues below. Assuming we have strong reasons to not use soft-state, it would be worth including some text in the draft to motivate that decision. (editorial) Can we consolidate the ABNF rather than have it scattered throughout? Specifics: 3. > Since the translation operation is based on local policy or local > data (such as registrations), it is the vehicle by which a > request is > delivered directly to an endpoint, when it would not otherwise be > possible to. (editorial) This is not generally true. The "exploder" use case, which is one of the biggest motivators for consent, does not in any way prevent a sender from directly sending to a particular recipient without going through the exploder. This _only_ seems true for proxy/ registrars, and then only when permission is applied at policy- execution time rather than policy manipulation time. (Maybe I'm missing something.) 4.3 > There are several mechanisms to implement store-and-forward message > services (e.g., with an instant message to email gateway). Any of > these mechanisms can be used between a user agent and its store- > and- > forward server as long as they agree on which mechanism to use. > Therefore, this framework does not make any recommendation on the > interface between user agents and their store-and-forward servers. It is not clear to me if store-and-forward servers are a required (i.e. normative) part of the consent architecture, or if they are just something that might exist. I infer the first, considering the draft always assumes the existence of them, and there are clear issues about handling permissions when you can't get a MESSAGE to the recipient. If we are going to normatively require them, then I have some heartburn about the fact that there is no specification of how they work. I don't expect _this_ doc to specify that, but it should be somewhere. In particular, if we are going to architecturally require them, we as a community should be concerned about interoperability between S&F servers and arbitrary UAs, which this document _explicitly_ punts on. Section 4.3: > Relays always > include SIP URIs and may include HTTP [2] URIs for this purpose. > Consequently, recipients provide relays with permissions using SIP > PUBLISH requests or HTTP GET requests. Is there normative text somewhere requiring this? If so, I missed it. Section 5.3: (General to section): (editorial) The organization could use some work. The section opened discussing what bodies go into the MESSAGE request, then talked about authentication, then comes _back_ to content of the MESSAGE request. I suggest consolidating these. > Relays MUST obtain permissions from potential recipients before > adding them to their translation logics. Can we make retroactive normative requirements on things like proxy/ registrars? Maybe this should be "Relays that implement this framework MUST..." > MESSAGE requests sent to request permissions MUST include a > permission document and SHOULD include a human-readable part in > their > bodies. MESSAGE requests also carry a body part that contains the > same information as the permission document but in a human-readable > format so that user agents that do not understand permission > documents can still process the request and display it in a > sensible > way to the user. (editorial) The last clause in the first sentence and the second sentence seem partially redundant. Also, we may need more spec on second sentence--how is a user whose UA does not understand this framework expected to do something useful with it? At least an example would be helpful Section 5.6: > A client gives a relay permission to execute the translation > described in a permission document by sending a SIP PUBLISH or an > HTTP GET request to one of the URIs to grant permissions > contained in > the document. Similarly, a client denies a relay permission to > execute the translation described in a permission document by > sending > a SIP PUBLISH or an HTTP GET request to one of the URIs to deny > permissions contained in the document. If I use PUBLISH, what goes in the body? Does it matter? I infer that an empty PUBLISH is just fine--if so some clarifying text would help. Also, if I deny permissions, and the sender tries again later, do I get a new permission request? is there a way to say "never bother me again"? > Relays need to ensure that the SIP PUBLISH or the HTTP GET request > received was generated by the recipient of the translation and > not by > an attacker. Normative text? 5.6.3: > The P-Asserted-Identity [4] mechanism can also be used to > authenticate the sender of a PUBLISH request. However, as discussed > in RFC 3325 [4], this mechanism should only be used within networks > of trusted SIP servers. (editorial) I seem to recall the statement being stronger than a non- normative should in 3325. 5.6.3: > Return routability tests do not provide the same level of > security as > SIP identity, but they provide a good-enough security level in > architectures where the SIP identity mechanism is not available > (e.g., the current Internet). (Editorial) By "good-enough", I think we mean "better-than-nothing" 5.8: > If a client loses this URI for some reason, it > needs to wait until it receives a new request produced by the > translation. Such a request will contain a Trigger-Consent header > field with a URI. That URI will have an escaped Refer-To header > field identifying the client (i.e., the recipient of the > translation). The client needs to send a REFER request to the > URI in > the Trigger-Consent header field in order to receive a MESSAGE > request from the relay. Such a MESSAGE request will contain a > permission document with a URI to revoke the permission that was > previously granted. This seems like a fairly kludgy way to work around the fact permissions live forever. If permissions were soft-state, then we could dispense with the escape-hatch for lost deny URLs. Also, one of the likely ways for me to lose the deny URL is if I change to a different UA, which may not support this framework _at_all_, leaving me now way to remove the permission. 5.10 Registrations General to section: This section makes me even more concerned about the fact that permission is hard-state. Consider that UA contact addresses tend to be _highly_ dynamic, and may identify a completely different UA tomorrow. For example, I get assigned an address of 10.0.0.1 by DHCP. Tomorrow, _you_ get the same address. The permission still exists unless someone removed it. 5.11 > A relay executing a translation that involves sending a request > to a > URI from which permissions were obtained previously SHOULD add a > Trigger-Consent header field to the request. If we are to stick with hard-state permissions, I think this should be a MUST. 6. IANA Considerations (editorial) Shouldn't we have some text or a table showing where these new header fields are allowed? Also, to show for which methods the 470 response is allowed.? 7. Security Considerations > Therefore, it is RECOMMENDED that relays performing > translations implement this framework. There is a bootstrapping problem here--we seem to be placing a normative requirement on devices that have been previously specified, such as proxy/registrars If so, this document needs to officially update those specs, right? > As pointed out in Section 5.6.3, when return routability tests are > used to authenticate recipients granting or denying permissions, > the > URIs used to grant or deny permissions need to be protected from > attackers. SIPS URIs provide a good tool to meet this requirement, > as described in [12]. The presence of store-and-forward servers, where the interface between S&F server and recipient is undefined make introduce security issues here. If the last hop is not SIP, then SIPS does not necessarily help. If we are going to leave these vague, then we should mention this in the security considerations. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 16 23:58:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZg46-0002Rc-Nq; Mon, 16 Oct 2006 23:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZg44-0002RQ-Rk for sip@ietf.org; Mon, 16 Oct 2006 23:56:28 -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 1GZg43-0001I4-E2 for sip@ietf.org; Mon, 16 Oct 2006 23:56:28 -0400 Received: from [192.168.1.106] (adsl-68-94-28-25.dsl.rcsntx.swbell.net [68.94.28.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9H3uIpE036070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Oct 2006 22:56:23 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03939304-4473-4E5A-BC8C-F39BEBCF078B@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Mon, 16 Oct 2006 22:56:01 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.2 (++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Sip List Subject: [Sip] WGLC comments for draft-ietf-sipping-consent-format-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, General comments: (editorial) Personal pet-peeve: It is much more friendly to the reader to use the form, "...defined in RFCXXX [8]", than to say "...defined in [8]." Otherwise they have to keep referring to the reference section. I realize that is hard to do with works-in- process, but we could use a descriptive name. (I mention this in general as it is pervasive to the draft.) 3. > This section defines the new conditions and actions defined by this > specification. This specification does not define any new > transformation. I am at a loss to understand how transformations would be used at all for this purpose. 3.1.1. > The elements and MUST contain a scheme when they > appear in a permission document. We are talking about the "id" attribute in each of those, correct? Also, is the element permissible in ? I don't understand how it would be used, particularly since the framework does not allow wildcarding of identity. > For PUBLISH requests that are > authenticated using the SIP Identity mechanism, the identity of > the sender of the PUBLISH request is equal to the SIP URI in the > From header field of the request, assuming that the signature in > the Identity header field has been validated. Should we have a normative statement that the signature MUST be validated? > P-Asserted-Identity [5], as described in [9]. For PUBLISH requests > that are authenticated using the P-Asserted-Identity mechanism, > the identity of the sender of the PUBLISH request is equal to > the > P-Asserted-Identity header field of the request. Need to mention the P-Asserted-Identity requires the request to have come from a trusted element. 3.1.2: > > The sender condition is matched against the URI of the sender of > the > request that is used as input for a translation. Sender conditions > can contain the same elements and attributes as identity > conditions. does this include the same rules about having a scheme in and ? Also, is allowed? It seems to make more sense for than for 3.1.2.2 > For requests that are authenticated using SIP Digest, the > identity of > the sender is set equal to the user and domain part of the SIP > Address of Record (AOR) for the user that has authenticated why not just the whole SIP AoR? That is, why did we mention user and domain parts, rather than just take the AoR URI as a whole? > For requests that are authenticated using RFC 3325 [5], the > identity > of the sender is equal to the username and domain parts of the SIP > URI in the P-Asserted-ID header field. If there are multiple > values > for the P-Asserted-ID header field (there can be one sip URI and > one > tel URI [10]), then each of them is used for the comparisons > outlined > in [8], and if either of them match a or element, it > is considered a match. why do we call out user and domain parts, instead of just taking the URI as a whole? 3.1.2.3 what are the consequences of being unable to convert the id? 3.2.1: The use of the transl-handling URIs seems under-specified to me. The framework document mentions you can send a SIP PUBLISH or an HTTP get. In the case of publish, what do you publish? An empty document? HTTP is easier to figure out, but it is still not explicit. What about other schema? 4. Should the two elements be elements instead? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 17 00:15:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgJF-0004wG-VW; Tue, 17 Oct 2006 00:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgJD-0004pJ-Uo for sip@ietf.org; Tue, 17 Oct 2006 00:12:07 -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 1GZgJC-00062X-LO for sip@ietf.org; Tue, 17 Oct 2006 00:12:07 -0400 Received: from [192.168.1.106] (adsl-68-94-28-25.dsl.rcsntx.swbell.net [68.94.28.25]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9H4C06V037982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Oct 2006 23:12:05 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Mon, 16 Oct 2006 23:11:44 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 2.2 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Sip List Subject: [Sip] WGLC comments on draft-ietf-sipping-pending-additions-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, This draft looks mostly done to me--my comments are pretty trivial. (Or maybe I am just too tired to be picky right now :-) ) Section 2: > Any SIP server, be it a proxy, B2BUA (Back-to-Back User Agent), or > some hybrid, that receives a request, translates its Request-URI > into > one or more next-hop URIs (i.e., recipient URIs), and delivers the > request to those URIs. (editorial) Partial paragraph? I think this is the definition of a "relay", but the term never appears. 5.1 > The name of this event package is "pending-additions". Since the use of this package is scoped to the consent-framework, could we have less generic package name? Maybe "pending-consent" or "consent-pending-additions"? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 17 01:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhvh-0005Qd-FD; Tue, 17 Oct 2006 01:55:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhvf-0005QV-Jd for sip@ietf.org; Tue, 17 Oct 2006 01:55:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhvX-00089Q-0h for sip@ietf.org; Tue, 17 Oct 2006 01:55:55 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 39BA78D8; Tue, 17 Oct 2006 07:55:44 +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, 17 Oct 2006 07:55:43 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 07:55:43 +0200 Received: from [131.160.36.27] (EH3I2003TGFCPET-131160036027.lmf.ericsson.se [131.160.36.27]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 77B822348; Tue, 17 Oct 2006 08:55:43 +0300 (EEST) Message-ID: <4534705F.8030701@ericsson.com> Date: Tue, 17 Oct 2006 08:55:43 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Sip] WGLC: draft-ietf-sip-consent-framework-00 References: <5D1A7985295922448D5550C94DE291804A5D7F@DEEXC1U01.de.lucent.com> <20060927130613.q97z7cd0p4dcc8og@webmail.versatel.nl> <4530B11A.2080302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 05:55:43.0462 (UTC) FILETIME=[E1FCD860:01C6F1B0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "sip@ietf.org" , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Ben, > I am reviewing in a separate email, but I will state here that I do > like the publish approach better than the refer approach good. > --but why use the additional step of the Trigger-Consent? Why not > just send the "deny" URL in each translated request, and let the > recipient skip the step of requesting a new permissions document just > to get the deny URL? (I'm sure there is a very good reason that we > have already discussed.) yes, it was discussed. That would require the relay to use SIPS for *all* its outgoing requests. Otherwise, attackers could get their hands on the URI to revoke permissions and perform a DoS attack. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 17 02:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBy-0002Fm-9K; Tue, 17 Oct 2006 02:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBf-0001ji-SV for sip@ietf.org; Tue, 17 Oct 2006 02:12:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZi2k-0000MN-NU for sip@ietf.org; Tue, 17 Oct 2006 02:03:15 -0400 Received: from [10.82.216.195] (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9H56OmD003260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 00:06:30 -0500 Message-ID: <45347188.5090400@softarmor.com> Date: Tue, 17 Oct 2006 01:00:40 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 References: <445B5F21.90909@cisco.com> <6290D568-9F19-4CAE-9F1B-40BD19FBEE63@softarmor.com> <4534028A.4020501@cisco.com> In-Reply-To: <4534028A.4020501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIP IETF , Paul Kyzivat , "jdrosen >> Joseph Drommer" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 dont think its crazy dean. Its more or less what I'm planning on > putting in the revision to route-construct. > Groovy. Now just remember that the next time I say something everybody thinks is crazy -- maybe five years later, it will sound more reasonable. Except this statement, of course, which will always sound crazy. ;-) -- 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 Oct 17 02:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiCu-0002sA-BE; Tue, 17 Oct 2006 02:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBm-0001xD-F4 for sip@ietf.org; Tue, 17 Oct 2006 02:12:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZhyd-0008SE-LC for sip@ietf.org; Tue, 17 Oct 2006 01:59:00 -0400 Received: from [10.82.216.195] (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9H52Hhv003230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 00:02:18 -0500 Message-ID: <45347091.1040302@softarmor.com> Date: Tue, 17 Oct 2006 00:56:33 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: CLHaft@aol.com Subject: Re: [Sip] Question on REGISTER References: In-Reply-To: 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@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 CLHaft@aol.com wrote: > I'm working on a gateway between a proprietary system and SIP. One of our > new projects involves sending REGISTERs on behalf of some of our users to a > third party server. They are pointing at section 10.2 of RFC 3261 where it > states: > > UAs MUST NOT send a new registration (that is, containing new Contact > header field values, as opposed to a retransmission) until they have > received a final response from the registrar for the previous one or > the previous REGISTER request has timed out. > > Does this really mean that our gateway must really wait for a response for > one user before we can send a REGISTER for a second user? This is what we are > being told by the third-party vendor of the registration server. I find it > hard to believe that this is the intent of the RFC, especially since it allows > for stateless proxies to be in the path, where they would not be able to do > this. Paul is correct that this section 10.2 text really refers to REGISTER requests with the same request-URI and To: value launched by a single UA, and its intent is to prevent "stacking up" of pending requests that are effectively going to cancel each other out anyhow. However, you may still want to do some sort of flow control or pacing on a sequence of REGISTER requests. Many registrars will fall over or at least get blocked up and start dropping requests if they're hit with too many overlapping requests. This is why the "avalanche restart" problem (where perhaps many UAs served by a single registrar reset at the same time due to a power failure) is such a big problem for large systems. Serializing the requests is probably the absolute safest flow control model. Note that this places no real dependencies on proxies, just on multiuser UAs. By serialization, I mean that the UA does not start a new register request until it has received a 200 OK (or other final response) to the preceding request. More sophisticated systems might launch REGISTER requests at some rate-per-second, with reasonable numbers for real hardware probably ranging from 4 to 400. Certainly if you drop 4,000 registration requests on a server within a 1-second window you are going to see some massive not-workingness. -- 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 Oct 17 03:22:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjED-0007OV-VR; Tue, 17 Oct 2006 03:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDw-00073H-I6 for sip@ietf.org; Tue, 17 Oct 2006 03:18:53 -0400 Received: from web31914.mail.mud.yahoo.com ([68.142.207.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZjDq-0003U6-UF for sip@ietf.org; Tue, 17 Oct 2006 03:18:52 -0400 Received: (qmail 52281 invoked by uid 60001); 17 Oct 2006 07:18:46 -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=CmTeJLTh9YQBz1QeVGATvCf04nZlavizOGcmtYtFHT8AeVAGd2HtgZHSAOUGO+tFViq2I+DXk6vX1gVOGYLAOYd/gZZb7zmfHdn288LvB/tHEFE6ullCDoDC2WWpVZI5cFe/OTlXVGF7TYR02SbpO3NpUHd0ay/JzlkxxnGg4tI= ; Message-ID: <20061017071846.52279.qmail@web31914.mail.mud.yahoo.com> Received: from [59.95.160.9] by web31914.mail.mud.yahoo.com via HTTP; Tue, 17 Oct 2006 00:18:46 PDT Date: Tue, 17 Oct 2006 00:18:46 -0700 (PDT) From: Vijay Gurbani To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.0 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] draft-ietf-sip-connect-reuse-07 X-BeenThere: sip@ietf.org X-Mailman-Version: 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: connect-reuse has been updated. Until it is available in the IETF archives, you can get a copy from: http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-07.txt http://scm.sipfoundry.org/rep/ietf-drafts/gurbani/connect-reuse/draft-ietf-sip-connect-reuse-07.html The major changes are making TCP as a first-class citizen for connection reuse, and clarifying some aspects of it based on the WG discussion we had on the list. My hope is to have this draft be done before Dean's next birthday ;-) Please go through the draft and post any comments or concerns. Thank you. - vijay - vijay -- Vijay K. Gurbani vgurbani@yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 Oct 17 10:30:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpvA-0001Pb-1t; Tue, 17 Oct 2006 10:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpv8-0001Ox-9J for sip@ietf.org; Tue, 17 Oct 2006 10:27:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpv0-0006UN-DU for sip@ietf.org; Tue, 17 Oct 2006 10:27:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Oct 2006 07:27:46 -0700 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 k9HERkue015524; Tue, 17 Oct 2006 10:27:46 -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 k9HERjYJ009879; Tue, 17 Oct 2006 10:27:46 -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, 17 Oct 2006 10:27:45 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 10:27:44 -0400 Message-ID: <4534E860.1050100@cisco.com> Date: Tue, 17 Oct 2006 10:27:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Question on REGISTER References: <45347091.1040302@softarmor.com> In-Reply-To: <45347091.1040302@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 14:27:44.0940 (UTC) FILETIME=[696A5EC0:01C6F1F8] DKIM-Signature: a=rsa-sha1; q=dns; l=3089; t=1161095266; x=1161959266; 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=20on=20REGISTER |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3DyDooipuEhcCESUaMNqXytABoo9o=3D; b=Bp/0yldFgqWX7QYQxy2P/0OeFICMNt2IYuL9dRP4BtsSkfHX/YTubZe1aCs4JxIeBwKtUlHN EQ+cHQDozONiJl803o6i3E2ReW39Axj3PMVyV/3NYr71M+zD+LQBIE4q; 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: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, CLHaft@aol.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 do agree with Dean on this. I like the phrase "massive non-workingness". Another Dean-ism for the book. The server you are registering to has no business sending you a 491 when you send a second REGISTER to a different AOR. But it certainly can send you a 503 if you are trying to send 4000 concurrent REGISTERs. Paul Dean Willis wrote: > CLHaft@aol.com wrote: >> I'm working on a gateway between a proprietary system and SIP. One >> of our new projects involves sending REGISTERs on behalf of some of >> our users to a third party server. They are pointing at section 10.2 >> of RFC 3261 where it states: >> >> UAs MUST NOT send a new registration (that is, containing new Contact >> header field values, as opposed to a retransmission) until they have >> received a final response from the registrar for the previous one or >> the previous REGISTER request has timed out. >> >> Does this really mean that our gateway must really wait for a response >> for one user before we can send a REGISTER for a second user? This >> is what we are being told by the third-party vendor of the >> registration server. I find it hard to believe that this is the >> intent of the RFC, especially since it allows for stateless proxies >> to be in the path, where they would not be able to do this. > > Paul is correct that this section 10.2 text really refers to REGISTER > requests with the same request-URI and To: value launched by a single > UA, and its intent is to prevent "stacking up" of pending requests that > are effectively going to cancel each other out anyhow. > > However, you may still want to do some sort of flow control or pacing on > a sequence of REGISTER requests. Many registrars will fall over or at > least get blocked up and start dropping requests if they're hit with too > many overlapping requests. This is why the "avalanche restart" problem > (where perhaps many UAs served by a single registrar reset at the same > time due to a power failure) is such a big problem for large systems. > > Serializing the requests is probably the absolute safest flow control > model. Note that this places no real dependencies on proxies, just on > multiuser UAs. By serialization, I mean that the UA does not start a new > register request until it has received a 200 OK (or other final > response) to the preceding request. > > More sophisticated systems might launch REGISTER requests at some > rate-per-second, with reasonable numbers for real hardware probably > ranging from 4 to 400. Certainly if you drop 4,000 registration requests > on a server within a 1-second window you are going to see some massive > not-workingness. > > > -- > 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 Oct 17 14:53:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZu0A-0002Z9-TQ; Tue, 17 Oct 2006 14:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZu0A-0002Z2-97 for sip@ietf.org; Tue, 17 Oct 2006 14:49:22 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZu05-0004Y8-QV for sip@ietf.org; Tue, 17 Oct 2006 14:49:22 -0400 Received: (qmail 28027 invoked by uid 0); 17 Oct 2006 18:49:02 -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 < >; 17 Oct 2006 18:49:02 -0000 Message-ID: <003201c6f21c$f14c66c0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <452FADDE.3040400@cisco.com> Subject: Re: [Sip] New draft on mid-dialog failover and proxy discovery in SIPoutbound Date: Tue, 17 Oct 2006 20:49:14 +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: 9ed51c9d1356100bce94f1ae4ec616a9 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 Jonathan, 2 questions and 1 minor remark: 1) Why would the REGISTER bounce a second time (305), after receiving 401? The request being retried is the one constructed after having received the 305, so shouldn't it already contain the proper Route headers? 2) For proxy 3, wouldn't the UA use a new reg-id? (minor remark: several ';lr' missing in Path and Route URIs) Regards, Jeroen Jonathan Rosenberg wrote: > I've just submitted a new draft that proposes a solution for outbound > proxy discovery and mid-dialog failover with SIP outbound. I hinted at > this solution last IETF meeting. The mechanism requires no state > replication in edge proxies, no DNS changes or configurations (if > anythign it simplifies it further from even normal SIP), is backwards > compatible with home proxies that don't support it, and allows folks > to continue to place stuff into record-routes and see it back again > for mid-dialog requests that get routed to backups. > > As an interesting side effect, the mechanism also results in TCP/TLS > connection reuse which *does* work through NAT (unlike the existing > connect-reuse draft which does not), and addresses many of the > problems identified in Vijay's domain-certs document. It allows SIP > proxies to work more like the web model where you just need a single > cert like 'proxies.example.com' for the entire cluster and no other > hostname or IP address except this one is used. > > I admit its not an easy read; the mechanism itself is not too hard to > describe or implement; its much more complicated to explain why it > works. > Until it appears in the archives you can pick it up at: > http://www.jdrosen.net/papers/draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt > > Thanks, > 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 Tue Oct 17 16:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvos-0003v8-Uj; Tue, 17 Oct 2006 16:45:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvor-0003v2-Ad for sip@ietf.org; Tue, 17 Oct 2006 16:45:49 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZvoo-0007nn-S4 for sip@ietf.org; Tue, 17 Oct 2006 16:45:49 -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 k9HKjhE12124; Tue, 17 Oct 2006 16:45:43 -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] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Date: Tue, 17 Oct 2006 15:45:40 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110FA00C0@zrc2hxm2.corp.nortel.com> In-Reply-To: <45340774.9070806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt Thread-Index: AcbxclxxubDnjJGcRSuCRgOHkraARgAucMog From: "Brian Stucker" To: "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, 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 =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Monday, October 16, 2006 5:28 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Audet, Francois (SC100:3055); sip@ietf.org > Subject: Re: [Sip] RE: I-D=20 > ACTION:draft-rosenberg-sip-ua-loose-route-00.txt >=20 >=20 >=20 > Brian Stucker wrote: >=20 > > Jonathan, > >=20 > > Thanks for chronicling the discussion into a draft. > >=20 > > Just to build from Francois' comments (still reading through the=20 > > entire draft)... > >=20 > > If the UA is to look at the Route header to get the=20 > identity at which=20 > > it should accept the the request because the Request-URI=20 > could be who=20 > > knows what, isn't this confabulating the purposes of the=20 > two headers?=20 > > We'd be using a routing header for identity purposes. >=20 > See my response to Francois; I don't think thats what you=20 > want. If the UA wants to authorize an incoming request it=20 > uses a real security technique. >=20 > That said, I don't actually see anything wrong with using a=20 > Route haeder field for determining how to process a request.=20 > Thats already what proxies do and have been doing since the=20 > dawn of SIP. Fair enough. It was more of a textual/self-consistiency comment about the draft text as it stands. =20 > >=20 > >>From section 4.2, you mention that the exact purpose of the Route=20 > >>header > > is to indicate the next hop of the request, but now it=20 > would also have=20 > > to be the identity at that next hop that you're wishing to be=20 > > contacted as well. This assumes, of course, that Francois' concern=20 > > about the reliability of the Request-URI value (when you take into=20 > > account limited UA behavior) pans out (which I think it will). >=20 > I'm not sure I follow. With proxies, the Route header field=20 > identifies the next hop. WIth the introduction of loose=20 > routing in RFC3261, when received at that hop, it examines=20 > the URI, checks that it is 'its own', and proceeds if it is.=20 > I am merely extending that exact processing to UA. That=20 > doesn't mean that Route becomes an identity header akin to=20 > P-A-ID. It would mean that a UA would check that the Route=20 > haeder field matches its registered contact, if it wants.=20 > Though its not clear to me what security benefits are derived=20 > from that check in the absence of tls I must say. I agree. That's a better way of putting it I guess. >=20 > >=20 > > Thoughts? > >=20 > > Also, the comment at the bottom of section 4.2 about H-I seemed > > prejudicial/self-conflicting: > >=20 > > "Thirdly, the history specification is fairly complex and has seen=20 > > limited industry adoption. This should never be a reason to=20 > not use a=20 > > mechanism when its the right choice, but its a consideration that=20 > > warrants mentioning." > >=20 > > If something should never be a reason to exclude a=20 > mechanism then why=20 > > is it a consideration? >=20 > I was putting all of the cards on the table. I'm happy to=20 > remove this since claerly I was iffy on this as a reason=20 > myself. I have other concerns about history-info and they are=20 > there also in teh document. >=20 > Note that I'm not in fact proposing to get rid of H-I at all.=20 > I'm merely trying to frame when it is used (retargeting) vs.=20 > when its not (routing). If you consider the H-I insertion to only to apply to the last hop to the UA (as you are doing with the Route header) I don't see the problem. It's just a choice as to which header type you want to have the UA take a look at. It's simply storing off the request-URI prior to rewriting it to the contact value. The advantage in my mind is that H-I is a header that typically survives to the upper layers of an application built using SIP. Lower layers may simply strip the route header before the application gets it because it matches a user/interface on the device. Does anyone care that we're losing the contact used to reach the device at the upper layers of an application? Regards, Brian =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 Oct 17 17:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwI4-0004XH-0w; Tue, 17 Oct 2006 17:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwI1-0004X4-Lt; Tue, 17 Oct 2006 17:15:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwI0-0004RV-60; Tue, 17 Oct 2006 17:15:57 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HLFqJ6024217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 14:15:53 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.na.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HLDv7l014990; Tue, 17 Oct 2006 14:15:51 -0700 (PDT) Received: from NAEX07.na.qualcomm.com ([129.46.133.195]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:13:13 -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 Date: Tue, 17 Oct 2006 14:13:13 -0700 Message-ID: <90D469E18343DE47961207F6851040B3F5CEE5@NAEX07.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC: Comments on draft-ietf-sip-consent-framework-00.txt Thread-Index: AcbyMQ6YpsvCs3BaSGSz+hXlQaEHyA== From: "Mahendran, AC" To: X-OriginalArrivalTime: 17 Oct 2006 21:13:13.0853 (UTC) FILETIME=[0E93E2D0:01C6F231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, ac@qualcomm.com, drage@lucent.com, sipping@ietf.org, mary.barnes@nortel.com Subject: [Sip] WGLC: Comments on draft-ietf-sip-consent-framework-00.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 Gonzallo, Here are my comments on draft-ietf-sip-consent-framework-00. 1) Section 2 (editorial) " Translation operation: Operation by which a relay translates the request URI of an incoming request (i.e., the target URI) into one or more URIs (i.e., recipient URIs) which are used as the request URIs of one or more outgoing requests. Replace 2 instances of the "request URI" with "Request-URI". 2) Section 3 (editorial) "Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates, following its translation logic, the Request-URI into one or more additional URIs." Add "(target URI)" after "Request-URI" and "(recepient URIs)" after "one or more additional URIs". 3) Section 4 (Editorial) It would be good to add a few descriptive words to describe the ordering in the sequence of operations (i.e., manipulation, permission request, permission grant). Though strictly there is no ordering, normally, manipulation triggers permission requests, which then triggers permission grant. 4)Section 4.3 (Editorial): "Nevertheless, users are not on-line all the time and, so, sometimes are not able to receive MESSAGE requests." Replace "Nevertheless" with "However". 5) Section 4.4: "Consequently, recipients provide relays with permissions using SIP PUBLISH requests or HTTP GET requests." What are the contents/body of the PUBLISH request? Why only HTTP GET? Why can't the recepient use HTTP(XCAP) PUT to update the permissions document in the relay? Btw, is PUBLISH the only SIP method for the recepient to provide permissions? Why not allow MESSAGE as well? 6) Section 5.6.1: "Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) response and MUST NOT be processed further." The reason for SHOULD (as supposed to MUST) needs to be explained here. (The same comment applies to 5.6.2, 5.6.4). 7) Section 5.8 "At any time, if a client wants to revoke any permission, it uses the URI it received in the permission document to deny the permissions it previously granted. If a client loses this URI for some reason, it needs to wait until it receives a new request produced by the translation. " The usage of "client" in this paragraph is confusing. Based on the architecture diagram, it'd be better if we use "recepient" instead of "client". 8) Section 5.8 In figure 5, when the relay receives the REFER message, it needs to know which permissions document to the send to the recepient (for example, the recepient may be a part of multiple SIP URI lists). How does the relay server know which document B@example.com is requesting for?=20 Thanks, AC =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 Oct 17 17:21:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwLa-0005gx-RP; Tue, 17 Oct 2006 17:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwLZ-0005gO-3g for sip@ietf.org; Tue, 17 Oct 2006 17:19:37 -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 1GZwLX-0004op-Pd for sip@ietf.org; Tue, 17 Oct 2006 17:19:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2006 14:19:35 -0700 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 k9HLJZb7029072; Tue, 17 Oct 2006 14:19:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HLJXW4017508; Tue, 17 Oct 2006 14:19:33 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 14:19:35 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:19:34 -0700 Message-ID: <453548E5.2080707@cisco.com> Date: Tue, 17 Oct 2006 17:19:33 -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 References: <62B9B0847CC47543B6B3B5E26BD268E60E84F9F8@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60E84F9F8@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Oct 2006 21:19:34.0765 (UTC) FILETIME=[F19E71D0:01C6F231] DKIM-Signature: a=rsa-sha1; q=dns; l=1194; t=1161119975; x=1161983975; c=relaxed/simple; s=sjdkim2002; 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=20A=20Comment=20draft-ietf-sip-hitchhikers-guide-00.txt; X=v=3Dcisco.com=3B=20h=3DrlGn8/I5oVqh3Ga6TvLC3x7PDr0=3D; b=ttgO5t93axmjEPopLGgWRQE+AwzWXPpvgJ8PqXoFvESivqEd4H+0m+jBaSjg3noiMhQPf2hH 4PC70AitWbPOnIj2jOzpIRIIqxBHldP+HYLlUt9M5pqCllJKZHp2rQsu; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org Subject: [Sip] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.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 THanks for the comments, and apologies for the slow response. See below. Samir Srivastava wrote: > Hi, > > > > 1) Shouldn’t we have reference to the open bugs in this guide in > some form. Atleast a reference to bugzilla web site? That is not within the scope of this document. There is ongoing discussion on what to do with those bugs, no conclusion yet. But this document serves only to enumerate the SIP specifications. > > > > 2) It refers the RFC 2976 for SIP INFO. Shouldn’t it refer the RFC > 2833 there. We may be widening its scope to media too.. INFO is an existing normative extension to SIP and so it is referenced. That doesn't mean we are proposing it be used for DTMF; it just means its an extension. RFC 2833 is not a SIP extension, it is an RTP extension. So it is not included. -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 Oct 17 18:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZx9Q-0002BI-I5; Tue, 17 Oct 2006 18:11:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZx9P-0002AR-Lc for sip@ietf.org; Tue, 17 Oct 2006 18:11:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZx9N-0002kV-AI for sip@ietf.org; Tue, 17 Oct 2006 18:11:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 17 Oct 2006 15:11:04 -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 k9HMB40E022536 for ; Tue, 17 Oct 2006 15:11:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9HMB4W4018520 for ; Tue, 17 Oct 2006 15:11:04 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 15:11:04 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 15:11:04 -0700 Message-ID: <453554F7.9000003@cisco.com> Date: Tue, 17 Oct 2006 18:11:03 -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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 22:11:04.0477 (UTC) FILETIME=[233B14D0:01C6F239] DKIM-Signature: a=rsa-sha1; q=dns; l=1791; t=1161123064; x=1161987064; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Updated=20hitchhikers=20guide=20to=20SIP; X=v=3Dcisco.com=3B=20h=3Dn64rCZ5s9qlTqCFWonmrmK+ters=3D; b=Ta7vKViV5o/qYQ+XI01v9J6O8/77/T2LCMsUMQCyyp+BAEB0o/O0y8QfB+if5SgBh8fi4Tc7 OBOF/LOu8UB00rO2wnHmCordtRG6mW1FM2HhVLHh77Qzr+bOt1MGcwoV; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] Updated hitchhikers guide to 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've submitted an update to the hitchhikers guide. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-hitchhikers-guide-01.txt The changes are: * updated I-D reference for event-list to RFC 4662 * updated I-D reference for conference-package to RFC 4575 * updated I-D reference for sip-identity to RFC 4474 * updated I-D reference for sdp-new to RFC 4566 * updated I-D reference for comedia-tls to RFC 4572 * updated I-D reference for sdp-label to RFC 4574 * added I-D reference for draft-ietf-sip-xcap-config under OAM * added I-D reference for draft-ietf-sip-consent-framework under security * added I-D reference for draft-ietf-sip-saml * added I-D reference for draft-ietf-sipping-pending additions under event packages and security * changed I-D reference for draft-ietf-sipping-uri-list-subscribe to draft-ietf-sip-uri-list-subscribe * changed I-D reference for draft-ietf-sipping-uri-list-message to draft-ietf-sip-uri-list-message * changed I-D reference for draft-ietf-sipping-uri-list-conferencing to draft-ietf-sip-uri-list-conferencing * changed I-D reference for draft-ietf-sipping-multiple-refer to draft-ietf-sip-multiple-refer as a matter of statistics, there are currently 104 references from this document. The following core specs are still at I-D status: GRUU sip-outbound ICE connected-identity fork-loop-fix 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 Oct 17 18:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZxn0-0004y4-69; Tue, 17 Oct 2006 18:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZxmy-0004xu-Jj for sip@ietf.org; Tue, 17 Oct 2006 18:52:00 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZxmw-0005zU-5G for sip@ietf.org; Tue, 17 Oct 2006 18:52:00 -0400 Received: from s73602 (failure[71.56.187.87]) by comcast.net (rwcrmhc13) with SMTP id <20061017225157m1300m8q5ue>; Tue, 17 Oct 2006 22:51:57 +0000 Message-ID: <3b1901c6f23e$70c216e0$0300a8c0@china.huawei.com> From: "Spencer Dawkins" To: "IETF SIP List" References: <453554F7.9000003@cisco.com> Subject: Re: [Sip] Updated hitchhikers guide to SIP Date: Tue, 17 Oct 2006 17:48:51 -0500 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: 386e0819b1192672467565a524848168 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Most of my comments on version 00 were pretty conceptual, but this one 3. Core SIP Specifications RFC XXXX: Enhancements for Authenticated Identity Management in SIP (S) RFC XXXX [28] defines a mechanism for providing a cryptographically verifiable identity of the calling party in a SIP request. Also known as "SIP Identity", this mechanism provides an alternative to RFC 3325. It has seen little deployment so far, but its importance as a key construct for Spencer: NO idea what "almost also" is doing in this sentence, but assume that you meant to say something here. Just flagging for you. almost also anti-spam techniques makes it a core part of the SIP specifications. probably really needed to get changed... Thanks, Spencer (previous e-mail available at http://www1.ietf.org/mail-archive/web/sip/current/msg14040.html, just for reference) ----- Original Message ----- From: "Jonathan Rosenberg" To: "IETF SIP List" Sent: Tuesday, October 17, 2006 5:11 PM Subject: [Sip] Updated hitchhikers guide to SIP > I've submitted an update to the hitchhikers guide. Until it appears in the > archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-hitchhikers-guide-01.txt > > The changes are: > > * updated I-D reference for event-list to RFC 4662 > * updated I-D reference for conference-package to RFC 4575 > * updated I-D reference for sip-identity to RFC 4474 > * updated I-D reference for sdp-new to RFC 4566 > * updated I-D reference for comedia-tls to RFC 4572 > * updated I-D reference for sdp-label to RFC 4574 > > * added I-D reference for draft-ietf-sip-xcap-config under OAM > * added I-D reference for draft-ietf-sip-consent-framework under > security > * added I-D reference for draft-ietf-sip-saml > * added I-D reference for draft-ietf-sipping-pending additions under > event packages and security > > * changed I-D reference for draft-ietf-sipping-uri-list-subscribe to > draft-ietf-sip-uri-list-subscribe > * changed I-D reference for draft-ietf-sipping-uri-list-message to > draft-ietf-sip-uri-list-message > * changed I-D reference for draft-ietf-sipping-uri-list-conferencing to > draft-ietf-sip-uri-list-conferencing > * changed I-D reference for draft-ietf-sipping-multiple-refer to > draft-ietf-sip-multiple-refer > > > as a matter of statistics, there are currently 104 references from this > document. The following core specs are still at I-D status: > > GRUU > sip-outbound > ICE > connected-identity > fork-loop-fix > > 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 From sip-bounces@ietf.org Tue Oct 17 19:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZykH-0006Mo-Bn; Tue, 17 Oct 2006 19:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZykF-00064Q-A0 for sip@ietf.org; Tue, 17 Oct 2006 19:53:15 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZykE-0002CX-7j for sip@ietf.org; Tue, 17 Oct 2006 19:53:15 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9HNqwI03236; Tue, 17 Oct 2006 17:52:58 -0600 Message-ID: <45356CD9.4040801@ntt-at.com> Date: Tue, 17 Oct 2006 16:52:57 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> <452B9E1C.4030804@cisco.com> <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> <452D223A.8080403@cisco.com> In-Reply-To: <452D223A.8080403@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a Cc: Cullen Jennings , SIP , "Elwell, John" , Jon Peterson , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Although using P-A-ID may look like a good approach for this, I don't know if it's really a good idea as it seems to change the semantics of P-A-ID. Also, it may generates some issues when P-A-ID already exists in the message along with connected-identity. Following illustrates potential problems. connected-id(FROM): carol@b.com P-A-ID: carol@b.com Now, following the proposal by John when Case 2 is deployed, and assuming the verification of identity failed, it will still forward the message as it is if we allow Case 2. When UAS receives the request it will see both the identity-info/header and P-A-ID with the value equivalent to the value in the FROM header.. If UAS has no ability to verify the signature itself, it will assume that the verification worked. P-A-ID looks like a good place to indicate the success of the verification but it might need something else. As for Cullen's comments. I agree with Paul here, if the security policy at the verification side would allow request without identity, it should forward the request even if the verification fails. Lastly, if P-A-ID value is used in some context, changing the value may cause some problem as well(Assuming P-A-ID was there but a different value from FROM value > verifier after verification succeeds change the P-A-ID value to that of FROM). Regards Shida Paul Kyzivat wrote: > > > Cullen Jennings wrote: >> >> I'm generally on board with things like you are suggesting below and >> what is suggested in draft-rosenberg-sip-identity-coexistence. >> However, I want to think very carefully about the security properties >> of not rejecting things that failed based on security properties - >> I'm not sure what I think of this yet. >> >> Any time you allow a security action that failed to continue sending >> the request downstream, you run the risk that something further down >> stream assumes that the security action worked because it must have >> happened upstream. Clearly from a security point of view it would be >> better not to have upstream elements do the security validation for a >> downstream element but we did decide long ago that when doing >> Identity we were going to allow for this so that we could migrate >> from UAs that do not support Identity to system that does. >> >> So let me flip this around the other way and ask - do we really need >> to allow for a request that failed verification to not result in an >> error? > > I think the poster child for this is when the error is 437 Unsupported > Certificate. > > In this case the caller may be trapped. It has an identity service it > can't control, that unconditionally adds an identity. And then the > callee has an authentication verifier in front of it. As things stand, > that verifier is required to reject requests with certs it doesn't > understand, even in cases where it will permit requests with no > identity at all. > > Paul > >> Are there use cases where the verification would fail and we really >> do want to continue with the message? If these cases would only >> happen in a fairly broken system, then it might not be worth the >> security problems they would cause. I don't know what I think but I >> am interested in where we might need this and if there might be other >> ways to skin the cat in those situations. >> >> Cullen >> >> >> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: >> >>> John, >>> >>> What you outline below is exactly what I had in mind. >>> >>> Paul >>> >>> Elwell, John wrote: >>>> Paul, >>>> Dan Wing made a suggestion that P-Asserted-Identity would fulfil your >>>> requirement. I guess it would work like this. >>>> A Verifier not located at the UAS would attempt to verify the >>>> signature in >>>> the Identity header field. >>>> - Case A - verification succeeds. The Verifier inserts into the >>>> forwarded >>>> request a P-Asserted-Identity header field containing the verified >>>> URI (from >>>> the From header field) in the forwarded request. The Identity and >>>> Identity-Info header fields will still be present and available should >>>> another verifier be encountered downstream. >>>> - Case B - verification fails but request not rejected. The >>>> verifier is >>>> unable to verify (e.g., because it can't dereference the URL) but >>>> according >>>> to policy does not reject the request. It simply forwards the >>>> request as is. >>>> If there is a further verifier downstream, that too can attempt to >>>> verify >>>> the signature. >>>> - Case C - verification fails but request is rejected. The verifier is >>>> unable to verify (e.g., bad signature) and according to policy it >>>> rejects >>>> the request. >>>> A UAS that does not contain a verifier can simply use >>>> P-Asserted-Identity, >>>> if present. >>>> This seems to have some synergy with >>>> draft-rosenberg-sip-identity-coexistence. In fact the relaxation of >>>> rules >>>> concerning rejection by a verifier that is unable to verify a >>>> signature >>>> might be beneficial to that proposal. >>>> I will omit discussion of the mechanics of documentation until I >>>> see what >>>> reaction there is to the technical proposal. >>>> John >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October >>>>> 2006 13:54 >>>>> To: Elwell, John >>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>> >>>>> >>>>> >>>>> Elwell, John wrote: >>>>>> Paul, >>>>>> >>>>>> Your message arrived just after I had submitted 02, so your >>>>> comments are not >>>>>> taken into account in that version. However, I felt it was >>>>> useful to get 02 >>>>>> out as a baseline for further discussion. >>>>> Sure. I too am interested in seeing other inputs on this subject. >>>>> >>>>>> It seems the remaining issue is whether to add an explicit >>>>> indication of >>>>>> removal of the Identity header field by a verifier that has >>>>> been unable to >>>>>> verify the signature. Whilst this may make sense, I am >>>>> concerned it starts >>>>>> to go beyond the scope of connected-identity, so I would like other >>>>>> opinions, especially from the chairs and from the authors >>>>> of Identity. >>>>> >>>>> Rather than adding something to indicate that identity has been >>>>> *removed* due to failure to verify, I am advocating adding >>>>> something to indicate that verification has *succeeded*, while >>>>> leaving the identity header in place. In this way, a downstream >>>>> element may *either* trust the info added by the verifier or do >>>>> its own verification of the identity header. >>>>> >>>>> Of course this is only significant if the verifier is doing work >>>>> for downstream elements, and not for itself. >>>>> >>>>> Paul >>>>> >>>>>> John >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 05 October >>>>>>> 2006 16:29 >>>>>>> To: Elwell, John >>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Elwell, John wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> So your proposal is that the connected-identity RFC should >>>>>>> update RFC 4474 >>>>>>>> to somehow relax rules at a verifier. Correct? >>>>>>> Yeah, I think so. >>>>>>> >>>>>>>> So the next question concerns the way in which these >>>>> rules should be >>>>>>>> relaxed. One problem with the verifier not being located at >>>>>>> the UAS but at >>>>>>>> some proxy is that the UAS might be configured always to >>>>>>> trust identities >>>>>>>> received in requests via the verifier's proxy if an >>>>>>> Identity header field is >>>>>>>> present, on the assumption that the signature has been >>>>>>> checked by the >>>>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>>>> not reject a >>>>>>>> request with a bad signature, should remove the Identity >>>>>>> header field (and >>>>>>>> also Identity-Info) before forwarding the request towards >>>>>>> the target. >>>>>>> >>>>>>> (I think I have seen someone propose combining the use of >>>>>>> Identity and P-Asserted-Identity, though I don't recall the >>>>>>> details, or which draft it was. So what I am about to say might >>>>>>> bear no >>>>> relationship to that.) >>>>>>> I could see how Identity might be used between trust >>>>> domains, while >>>>>>> P-Asserted-Identity is used within a trust domain. In that case, >>>>>>> a verifier might run at the entry point to a trust domain and if >>>>>>> verification succeeds, insert a P-Asserted-Identity header with >>>>>>> a corresponding identity. It then might, or might not, remove >>>>>>> the Identity header. Recipients within the trust domain could >>>>>>> then use P-Asserted-Identity as the source of identity info. (In >>>>>>> this scenario, an identity header would only be added to >>>>>>> requests when they leave the trust domain.) >>>>>>> >>>>>>> In this kind of environment, it is only necessary for the >>>>> verifier to >>>>>>> omit the P-Asserted-Identity header when verification fails. >>>>>>> >>>>>>>> Under what conditions should a verifier remove an Identity >>>>>>> header field >>>>>>>> rather than rejecting with 436/437/438? My inclination >>>>>>> would be to leave it >>>>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>>>> concerned, and >>>>>>>> then make more precise statements concerning mid-dialog requests. >>>>>>>> Alternatively the update to RFC 4474 could just relax the >>>>> rules for >>>>>>>> mid-dialog requests. I think there is some merit in >>>>>>> relaxing the rules in >>>>>>>> general, because otherwise there might be situations where >>>>>>> a legitimate >>>>>>>> caller cannot establish a call because an Authentication >>>>>>> Service (outside >>>>>>>> the UAC's control) is inserting an unverifiable signature >>>>> (e.g., in >>>>>>>> Identity-Info placing a URL that the Verifier cannot >>>>>>> dereference for some >>>>>>>> reason). >>>>>>> What you say sounds reasonable to me. >>>>>>> >>>>>>> There is however some risk to having a verifier remove >>>>> identity. The >>>>>>> problem would be when there are potentially multiple >>>>> verifiers that >>>>>>> don't trust one another. If an early one removes the >>>>> header, then it >>>>>>> prevents a subsequent verifier from doing its own verification. >>>>>>> >>>>>>> This could come up if a request transits a domain on the way to >>>>>>> another domain. Each domain may wish to do its own verification. >>>>>>> >>>>>>> That is an advantage to having the verifier add something to the >>>>>>> request to indicate the result of its verification. >>>>>>> >>>>>>>> One consequence of the Verifier being separated from the >>>>>>> UAS is that we >>>>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>>>> its proxy (for >>>>>>>> similar reasons that you cited for the Authentication >>>>>>> Service earlier). So >>>>>>>> for mid-dialog requests we would need to mandate, or at >>>>>>> least recommend, >>>>>>>> that 436/437/438 should not be sent. >>>>>>> Right. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 >>>>>>>>> October 2006 01:44 >>>>>>>>> To: Elwell, John >>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Elwell, John wrote: >>>>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>>>> >>>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>>>> 436, 437 or 438, >>>>>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>>>> not by some >>>>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>>>>>>> in a proxy before the UAS? This rule would forbid that, >>>>>>>>> because it would cause that proxy to be call stateful. >>>>>>>>> >>>>>>>>> I think it would just be better to update the RFC, even though >>>>>>>>> that is a bit more trouble than not to. >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>> on the same >>>>>>>>>> dialog unless the From header field URI has changed, and in >>>>>>>>> such cases >>>>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>>>> Then a UAC, on >>>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>>>> This would allow >>>>>>>>>> business as usual on this dialog (but without the benefit >>>>>>>>> of connected >>>>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>>>> any change to RFC >>>>>>>>>> 4474, because verification is optional anyway. >>>>>>>>>> >>>>>>>>>> Would this work? >>>>>>>>>> >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 >>>>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>> >>>>>>>>>>> Cullen, Jon, >>>>>>>>>>> >>>>>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>>>>> you), I would greatly appreciate an opinion from each of you >>>>>>>>>>> on this remaining issue in connected-identity. Just to >>>>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to return >>>>>>>>>>> a 428 response if Identity is missing, but mandates the >>>>>>>>>>> sending of a 436, 437 or 438 response for certain errors >>>>>>>>>>> arising while verifying the signature. It seems that for mid >>>>>>>>>>> dialog requests this behaviour could be harmful. What does >>>>>>>>>>> the UAC for the mid dialog request do if it receives 436, >>>>>>>>>>> 437 or 438? If the mid-dialog request was solely for the >>>>>>>>>>> purpose of connected identity, it can give up and allow the >>>>>>>>>>> call to continue as is. But if the request was for some >>>>>>>>>>> other purpose (e.g., renegotiating the session because of >>>>>>>>>>> hold, say, or session timer refresh), the UAC really wants >>>>>>>>>>> it to work. For the normal case where the Authentication >>>>>>>>>>> Service is at a proxy, not at the UAC, the UAC cannot force >>>>>>>>>>> the Authentication Service to refrain from putting this >>>>>>>>>>> unverifiable signature in the mid-dialog request, so any >>>>>>>>>>> attempts to repeat the request would most likely be doomed >>>>>>>>>>> to getting the same response. >>>>>>>>>>> >>>>>>>>>>> It seems there are three things we could do, none very >>>>>>> attractive: >>>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>>>>> 4474 for a verifier by softening the requirements for >>>>>>>>>>> sending 436, 437 and 438 in response to mid-dialog requests. >>>>>>>>>>> But then a mid-dialog request from a rogue source would be >>>>>>>>>>> accepted. >>>>>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>>>>>>> at the AS. >>>>>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>>>>> way and therefore things like session refresh and session >>>>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>>>>>>> AS inserts an Identity header that gets rejected with 436, >>>>>>>>> 437 or 438. >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>> September 2006 19:26 >>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>>> >>>>>>>>>>>> John, >>>>>>>>>>>> >>>>>>>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>>>>>>> to say about this. >>>>>>>>>>>> >>>>>>>>>>>> It is of some concern to me that a call might fail >>>>>>>>> because of some >>>>>>>>>>>> problem with the identity mechanism when the same call >>>>>>> might have >>>>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>>>> >>>>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>>>> implementation of the verifier. What to do in the case of >>>>>>>>>>>> the conditions that >>>>>>>>>>> lead to these >>>>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>>>> generate the >>>>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>>>> message. And the >>>>>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>>>>> message, such as whether it is in-dialog or not. >>>>>>>>>>>> >>>>>>>>>>>> Does it require a change to 4474 to permit that kind >>>>> of policy? >>>>>>>>>>>> It would be annoying if the end user had no control over >>>>>>>>>>>> the insertion and verification of identity, and it resulted >>>>>>>>>>>> in calls failing that the user would like to permit. But I >>>>>>>>>>>> suppose that is itself >>>>>>> a policy >>>>>>>>>>>> decision. There are certainly enterprises that want to >>>>>>>>>>>> exert that kind of control over what users are permitted to >>>>>>>>>>>> do. >>>>>>>>>>>> >>>>>>>>>>>> Paul >>>>>>>>>>>> >>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>> Paul, >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with most of your points, and on reflection I think >>>>>>>>>>>> I agree that the >>>>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>>>> >>>>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>>>>> 'Use Identity >>>>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>>>> policy, so we could >>>>>>>>>>>>> say in connected-identity that policy should be to not >>>>>>> send 428. >>>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>>>> because RFC 4474 says >>>>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>>>> Interestingly, though, >>>>>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>>>>> procedures of >>>>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>>>>> given on how to >>>>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>>>> authoritative for the >>>>>>>>>>>>> domain. >>>>>>>>>>>>> >>>>>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>>>>> connected-identity >>>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>>>>> of mid-dialog >>>>>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>>>>> 4474 as well as >>>>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>>>>> to remove some of >>>>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>>>> >>>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>>>> responses will be sent, >>>>>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>>>>> inability to >>>>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>>>>> UPDATE or >>>>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>>>> session timer refresh >>>>>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>>>>> call will fail (in >>>>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>>>> the session >>>>>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>>>>> to caller ID >>>>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>>>> impossible to establish a >>>>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>>>> ability to rectify the >>>>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>>>> Authentication Service >>>>>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>>>>> In the connected >>>>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>>>> already established >>>>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>>>> >>>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>>>> wrong source, then >>>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>>>>> thing to do, and >>>>>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>>>>> indeed be the wrong >>>>>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>>>>> response codes can >>>>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>>>> >>>>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>>>> sending a 428 and >>>>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>>>> verifier might send. >>>>>>>>>>>>> John >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>>> September 2006 15:13 >>>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] When an >>>>>>>>>>>>>>>> Update is sent. Are there any conditions >>>>>>> under which >>>>>>>>>>>>>>>> it might be rejected. Bad identity for example. I think >>>>>>>>>>>>>>>> that >>>>>>>>>>>> might need a >>>>>>>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>>>>>>> an update >>>>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>>>> situation where it is >>>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>>>> purposes such as >>>>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>>>> because connected >>>>>>>>>>>>>>> identity fails. >>>>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>> I'm not sure about this. At the least I think this >>>>> one needs >>>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the >>>>>>>>>>>>>> conditions when >>>>>>>>>>>> it can be >>>>>>>>>>>>>> violated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>>>> challenge on an >>>>>>>>>>>>>> in-dialog request. In some cases it is the right >>>>> thing to do. >>>>>>>>>>>>>> A UA that imposes such a requirement will be >>>>> limited in what >>>>>>>>>>>>>> it can do, but that may still be right in some cases. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>>>> Identity header field >>>>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>> This requirement would force the authentication service to >>>>>>>>>>>> be dialog >>>>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>>>> back into the >>>>>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>>>>> to tell the >>>>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>>>>> results in one of >>>>>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>>>>> for the purpose of >>>>>>>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>>>>>>> identity there is >>>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>>>>> any further >>>>>>>>>>>>>>> action". >>>>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>>>>> purpose of the verifier is ultimately to drive an >>>>>>>>>>>>>> authorization >>>>> decision. If >>>>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>>>> identity, then the >>>>>>>>>>>>>> request should be permitted to continue as if the >>>>>>>>>>>>>> identity was not present. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unfortunately this would seem to require a revision to >>>>>>>>>>>>>> 4474 even though the paint is hardly dry on it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>>>>> cause the >>>>>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>>>>> *not* done, >>>>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>>>> change to 4474. >>>>>>>>>>>>>> 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 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 17 22:19:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0yU-0006Ec-Jh; Tue, 17 Oct 2006 22:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0yS-0006Cj-Bw for sip@ietf.org; Tue, 17 Oct 2006 22:16:04 -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 1GZv7X-0005sU-2C for sip@ietf.org; Tue, 17 Oct 2006 16:01:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2006 13:01:02 -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 k9HK12XF029862 for ; Tue, 17 Oct 2006 13:01:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HK12Aq015290 for ; Tue, 17 Oct 2006 13:01:02 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 17 Oct 2006 13:01:02 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 13:01:02 -0700 Message-ID: <4535367D.6030707@cisco.com> Date: Tue, 17 Oct 2006 16:01:01 -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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2006 20:01:02.0120 (UTC) FILETIME=[F8A9E280:01C6F226] DKIM-Signature: a=rsa-sha1; q=dns; l=1371; t=1161115262; x=1161979262; 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:Updated=20route=20construct=20specification; X=v=3Dcisco.com=3B=20h=3DtlZJ5bzlRfTld4/LJzDbwEGV3No=3D; b=l+30T6HehxAt80oqDsMIVhwgaI4EmiH2ZryZDich9pl/uO4FE8mFE025RrnRtC5VXVBdj6of ZJtrnObuHzb0oM3bo4TrqvQZ83hnXnussLOIReB727J3Ll2AmEwSucBT; Authentication-Results: sj-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] Updated route construct specification X-BeenThere: sip@ietf.org X-Mailman-Version: 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 updated this document. It is (once again) almost completely rewritten. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-02.txt Basically, it proposes to turn Service-Route into the inverse of Path, so that Service-Route/Path work more like record-routing. This is now specified in a way which is backwards compatible with IMS, which was an issue for the previous spec. I believe this makes service-route usable for the internet at large, and it is a key part of solving the sip-outbound mid-dialog failover problem. Its also WAY simpler than previous versions. The whole bit in there about redirections overriding route sets is now folded into the more general UA loose routing document I also published. Just to get some controversy thrown in there, the draft also specifies as part of its behavior that a UA register only a single contact at a time, and only that contact get reflected in the REGISTER response. 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 Oct 17 22:21:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga12Q-0001LW-JA; Tue, 17 Oct 2006 22:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga12N-00014h-UY for sip@ietf.org; Tue, 17 Oct 2006 22:20:08 -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 1Ga12M-0006M3-Gt for sip@ietf.org; Tue, 17 Oct 2006 22:20:07 -0400 Received: from [192.168.1.106] (adsl-68-94-21-164.dsl.rcsntx.swbell.net [68.94.21.164]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9I2JbmJ063634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Oct 2006 21:20:04 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Tue, 17 Oct 2006 21:19:32 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.2 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Sip List Subject: [Sip] WGLC comments for draft-ietf-sipping-consent-format-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, sent to SIP by mistake. Resending to SIPPING. Sorry for the duplicate.] Hi, General comments: (editorial) Personal pet-peeve: It is much more friendly to the reader to use the form, "...defined in RFCXXX [8]", than to say "...defined in [8]." Otherwise they have to keep referring to the reference section. I realize that is hard to do with works-in- process, but we could use a descriptive name. (I mention this in general as it is pervasive to the draft.) 3. > This section defines the new conditions and actions defined by this > specification. This specification does not define any new > transformation. I am at a loss to understand how transformations would be used at all for this purpose. 3.1.1. > The elements and MUST contain a scheme when they > appear in a permission document. We are talking about the "id" attribute in each of those, correct? Also, is the element permissible in ? I don't understand how it would be used, particularly since the framework does not allow wildcarding of identity. > For PUBLISH requests that are > authenticated using the SIP Identity mechanism, the identity of > the sender of the PUBLISH request is equal to the SIP URI in the > From header field of the request, assuming that the signature in > the Identity header field has been validated. Should we have a normative statement that the signature MUST be validated? > P-Asserted-Identity [5], as described in [9]. For PUBLISH requests > that are authenticated using the P-Asserted-Identity mechanism, > the identity of the sender of the PUBLISH request is equal to > the > P-Asserted-Identity header field of the request. Need to mention the P-Asserted-Identity requires the request to have come from a trusted element. 3.1.2: > > The sender condition is matched against the URI of the sender of > the > request that is used as input for a translation. Sender conditions > can contain the same elements and attributes as identity > conditions. does this include the same rules about having a scheme in and ? Also, is allowed? It seems to make more sense for than for 3.1.2.2 > For requests that are authenticated using SIP Digest, the > identity of > the sender is set equal to the user and domain part of the SIP > Address of Record (AOR) for the user that has authenticated why not just the whole SIP AoR? That is, why did we mention user and domain parts, rather than just take the AoR URI as a whole? > For requests that are authenticated using RFC 3325 [5], the > identity > of the sender is equal to the username and domain parts of the SIP > URI in the P-Asserted-ID header field. If there are multiple > values > for the P-Asserted-ID header field (there can be one sip URI and > one > tel URI [10]), then each of them is used for the comparisons > outlined > in [8], and if either of them match a or element, it > is considered a match. why do we call out user and domain parts, instead of just taking the URI as a whole? 3.1.2.3 what are the consequences of being unable to convert the id? 3.2.1: The use of the transl-handling URIs seems under-specified to me. The framework document mentions you can send a SIP PUBLISH or an HTTP get. In the case of publish, what do you publish? An empty document? HTTP is easier to figure out, but it is still not explicit. What about other schema? 4. Should the two elements be elements instead? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 17 22:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1QD-0001Lr-JB; Tue, 17 Oct 2006 22:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1QC-0001Lg-IP for sip@ietf.org; Tue, 17 Oct 2006 22:44:44 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga1QB-0001OM-5j for sip@ietf.org; Tue, 17 Oct 2006 22:44:44 -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 k9I2bxr22948; Tue, 17 Oct 2006 22:37: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] Question on REGISTER Date: Tue, 17 Oct 2006 21:44:40 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110FF752E@zrc2hxm2.corp.nortel.com> In-Reply-To: <4534E860.1050100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on REGISTER Thread-Index: Acbx+M8SymUUlFjqTjaFwCL0seCEQAAZN0vw From: "Brian Stucker" To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org, CLHaft@aol.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 IMHO--=20 Having implemented registrars and things that register with them. The RFC is designed to disallow registrations for the same target resource at the registrar. This means that ANYONE trying to register against a particular target resource at the registrar must wait their turn and no overlapping is allowed (the target resource's contact set is not allowed to change in parallel). Once the 200 OK to one registration is sent out though, the next guy in the queue is free to do their thing. This doesn't mean that the registrar has to send a 491 back to overlapping registrations from two different sources trying to register for the same target resource in parallel as long as their SIP transactions aren't overlapping. You should only get a 491 if you have a pending registration with the same SIP transaction context information (tags, callid, etc, matches a registration that is still being processed). BTW- You may want to have a systems engineer take a look at your pacing algorithm. Depending on the timer intervals involved, you're going to wind up with some wickedly sinusoidal traffic patterns from most obvious traffic spreading algorithms. Check that. Regards, Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, October 17, 2006 9:28 AM > To: Dean Willis > Cc: sip@ietf.org; CLHaft@aol.com > Subject: Re: [Sip] Question on REGISTER >=20 > I do agree with Dean on this. >=20 > I like the phrase "massive non-workingness". Another Dean-ism=20 > for the book. >=20 > The server you are registering to has no business sending you=20 > a 491 when you send a second REGISTER to a different AOR. But=20 > it certainly can send you a 503 if you are trying to send=20 > 4000 concurrent REGISTERs. >=20 > Paul >=20 > Dean Willis wrote: > > CLHaft@aol.com wrote: > >> I'm working on a gateway between a proprietary system and=20 > SIP. One=20 > >> of our new projects involves sending REGISTERs on behalf=20 > of some of=20 > >> our users to a third party server. They are pointing at section=20 > >> 10.2 of RFC 3261 where it states: > >> > >> UAs MUST NOT send a new registration (that is, containing new=20 > >> Contact header field values, as opposed to a =20 > retransmission) until=20 > >> they have received a final response from the registrar for the=20 > >> previous one or the previous REGISTER request has timed out. > >> =20 > >> Does this really mean that our gateway must really wait for a=20 > >> response for one user before we can send a REGISTER for a second=20 > >> user? This is what we are being told by the third-party=20 > vendor of=20 > >> the registration server. I find it hard to believe that=20 > this is the=20 > >> intent of the RFC, especially since it allows for=20 > stateless proxies=20 > >> to be in the path, where they would not be able to do this. > >=20 > > Paul is correct that this section 10.2 text really refers=20 > to REGISTER=20 > > requests with the same request-URI and To: value launched=20 > by a single=20 > > UA, and its intent is to prevent "stacking up" of pending requests =20 > > that are effectively going to cancel each other out anyhow. > >=20 > > However, you may still want to do some sort of flow control=20 > or pacing=20 > > on a sequence of REGISTER requests. Many registrars will=20 > fall over or=20 > > at least get blocked up and start dropping requests if they're hit=20 > > with too many overlapping requests. This is why the "avalanche=20 > > restart" problem (where perhaps many UAs served by a single=20 > registrar=20 > > reset at the same time due to a power failure) is such a=20 > big problem for large systems. > >=20 > > Serializing the requests is probably the absolute safest=20 > flow control=20 > > model. Note that this places no real dependencies on=20 > proxies, just on=20 > > multiuser UAs. By serialization, I mean that the UA does=20 > not start a=20 > > new register request until it has received a 200 OK (or other final > > response) to the preceding request. > >=20 > > More sophisticated systems might launch REGISTER requests at some=20 > > rate-per-second, with reasonable numbers for real hardware probably=20 > > ranging from 4 to 400. Certainly if you drop 4,000 registration=20 > > requests on a server within a 1-second window you are going to see=20 > > some massive not-workingness. > >=20 > >=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 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 Wed Oct 18 03:06:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5Su-0000au-Vd; Wed, 18 Oct 2006 03:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZp3Y-0006q5-37 for sip@ietf.org; Tue, 17 Oct 2006 09:32:32 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GZp3S-0000Nn-BU for sip@ietf.org; Tue, 17 Oct 2006 09:32:31 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Oct 2006 06:32:24 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9HDTxvV008290; Tue, 17 Oct 2006 06:29:59 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9HDWOPF011917; Tue, 17 Oct 2006 06:32:24 -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, 17 Oct 2006 06:32:24 -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] identity-coexistence: the value of signatures Date: Tue, 17 Oct 2006 06:32:02 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141200@namail5.corp.adobe.com> In-Reply-To: <453439DF.3000507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] identity-coexistence: the value of signatures Thread-Index: AcbxkKbpwOIDwe9STf2uGpxn0cHefgAX46hg From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 17 Oct 2006 13:32:24.0197 (UTC) FILETIME=[AE193350:01C6F1F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Wed, 18 Oct 2006 03:03:48 -0400 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 This is an excellent protocol centric argument about not trusting intermediaries for identity and security. Not to mention what evil intermediaries or compromised intermediaries can do.=20 Thanks, Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Monday, October 16, 2006 9:03 PM To: IETF SIP List Subject: [Sip] identity-coexistence: the value of signatures I have on my long list of drafts to revise before the deadline, the=20 identity-coexistence draft: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexist ence-00.txt There was a good thread back in August on this topic, driven off on some comments by Cullen. Here is the thread URL if you are interested: http://www1.ietf.org/mail-archive/web/sip/current/msg14996.html There were a few issues in this thread, but the biggest byfar is the=20 issue of what to do in transit domains that have b2bua which modify the=20 Contact or SDP, invalidating the signature. Consider, for example, a=20 chain of domains A->B->C->D. The caller is in A.com and the called party in B.com. The From header field of sip:caller@A.com is signed by a proxy in A.com. It goes through two transit providers B and C prior to=20 reaching D. If a b2bua in B or C are B2bUA the signature is invalidated. One proposal, that I think Cullen was arguing for unless I am mistaken,=20 was that if B modifies the message it resigns using its own cert. C=20 receives this, and if it trusts B it would resign with its cert too.=20 Then it arrives at D, who of course trusts A and so resigns it with its=20 own cert. THen, the idea is that teh UAS is configured to accept a=20 signature even if the domain in the cert doesn't match the From domain,=20 if the cert is from a configured list of good domains, which typically=20 is just one domain - its own, D.com. Hadriel posted in reply that if you do this, why bother with SIP=20 identity? May as well use P-Asserted-ID since you are back to transitive trust. And indeed I have to agree with this. The reason I felt that SIP=20 identity is superior to P-Asserted-ID is that I, in the terminating=20 domina, know exactly who the originating domain was, and I could use=20 that information to plug it into black/white lists, authorization rules, and so on, to decide whether to accept the call. The canonical use case I have for this is a call from spammers.com, who=20 gets service from their provider littlecountry.com, who gets service=20 from biginterconnectprovider.com, which connects to my own provider,=20 myprovider.com. Though there IS in fact transitive trust at each hop,=20 the net value of P-Asserted-ID is nil here. The reason is that the value of P-Asserted-ID is equal to the trustworthiness of the LEAST=20 trustworthy provider in the chain. In a transit situation, this=20 exponentially approaches zero. However with SIP identity, I can directly determine that this is coming from spammers.com and look them up in=20 sipspamhaus.org and reject their calls as a matter of local policy. So if you emloy resigning at each transit hop, you will basically=20 eliminate all of the benefit that SIP identity brings to the table, and=20 I think thats bad. Consequently, unless the transit is something like an anonymizing=20 provider (and there are legitimate use cases for it), which purposefully masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK=20 THROUGH TRANSIT B2BUA*. That is the cost of the increased security we get. 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 Oct 18 03:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5VP-0001kU-Ev; Wed, 18 Oct 2006 03:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBP-0001cx-1G for sip@ietf.org; Tue, 17 Oct 2006 02:12:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZiBC-00019Z-0B for sip@ietf.org; Tue, 17 Oct 2006 02:12:04 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C70A37A9 for ; Tue, 17 Oct 2006 08:10:01 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 08:10: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 Date: Tue, 17 Oct 2006 08:10:01 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503AF7B70@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] WG last-call for SIP/SigComp thread-index: AcbuzRndN0JXkkp7RxmzKDCgwAGyVwC5bSfQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 17 Oct 2006 06:10:01.0210 (UTC) FILETIME=[E13ECDA0:01C6F1B2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Wed, 18 Oct 2006 03:06:22 -0400 Subject: [Sip] FW: [rohc] WG last-call for SIP/SigComp X-BeenThere: sip@ietf.org X-Mailman-Version: 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: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: den 13 oktober 2006 15:40 To: rohc@ietf.org Subject: [rohc] WG last-call for SIP/SigComp > Soon after the publication of SigComp (RFC 3320), work with > a document defining the specifics of using SigComp for SIP > message compression was initialised. For various reasons, the > finalisation of this document has taken much more time than > anticipated, but me and the authors now believe it should be > ready for publication. This is an essential document for the > application of SigComp on SIP, and it is thus important that > we finally get it out of the pipe. We are therefore now > issuing a working group last-call on the following document: >=20 > draft-ietf-rohc-sigcomp-sip-03.txt > (for publication as Proposed Standard) >=20 > This will be the usual two-week WG last-call as suggested in > RFC 2418. Please direct last-call comments to the ROHC mailing > list rohc@ietf.org before Fri, 2006-10-27, 18:00 UTC. >=20 > /L-E >=20 > -------------------------------------- > Lars-Erik Jonsson > IETF ROHC WG Chair > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 8 404 29 61 >=20 > My opinions are my personal opinions and should not be considered > as the opinions of my employer, if not explicitly stated. >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 18 03:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga5Wb-0003cy-5h; Wed, 18 Oct 2006 03:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga0BD-0000XO-7U for sip@ietf.org; Tue, 17 Oct 2006 21:25:11 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga0BA-0000ha-OE for sip@ietf.org; Tue, 17 Oct 2006 21:25:11 -0400 Received: from rmailcenter08.comcast.net ([204.127.197.118]) by comcast.net (rwcrmhc15) with SMTP id <20061018012508m15009dh7re>; Wed, 18 Oct 2006 01:25:08 +0000 Received: from [71.204.170.228] by rmailcenter08.comcast.net; Wed, 18 Oct 2006 01:25:07 +0000 From: mary.barnes@comcast.net To: sip@ietf.org Date: Wed, 18 Oct 2006 01:25:07 +0000 Message-Id: <101820060125.4145.453582730001B36E0000103122007507849C0A029D0E0DD2979D0E03@comcast.net> X-Mailer: AT&T Message Center Version 1 (Apr 11 2006) X-Authenticated-Sender: bWFyeS5iYXJuZXNAY29tY2FzdC5uZXQ= MIME-Version: 1.0 X-Spam-Score: 1.7 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Wed, 18 Oct 2006 03:07:36 -0400 Cc: , gonzalo.camarillo@ericsson.com, dean.willis@cisco.com Subject: [Sip] WGLC draft-ietf-sip-consent-framework-00 X-BeenThere: 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="===============1938550019==" Errors-To: sip-bounces@ietf.org --===============1938550019== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_4145_1161134707_0" --NextPart_Webmail_9m3u9jl4l_4145_1161134707_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I'm posting this from my private email as my Outlook server has been down this afternoon and doesn't appear to be recovering this evening. Draft: draft-ietf-sip-consent-framework-00.txt Reviewer: Mary Barnes [mary.barnes@nortel.com] Review Date: 17 October 2006 Review Deadline: 17 October 2006 Status: WGLC Summary: This draft is on the right track but has an issue and a few nits, described in the review. Issues: ------- - Section 4.3: I share the concern that Ben raised in his review with regards to this framework not making any recommendations about (or defining) a store-and-forward mechanism. The off-line user issue is real and it would seem to be a large impediment to deployment of this functionality if there is not a recommendation for a must implement mechanism. I don't expect this document to define the functionality since it is more general, but it does seem a requisite for this draft. Nits: ------ - General: the term "Translation Logic" is used almost interchangeably with "Translation Operation", although only the latter term is defined in section 2. It would make this document a bit easier to follow, if a single term was used, provided they do mean the same thing. Also, there is sometimes an "s" added to the use of the word "logic" - this likely is incorrect and should be changed if that term remains in the document. -Section 3, 1st paragraph following Figure 1: the wording is a bit awkward and reads as if it's redundant, although it's not. Propose rewording to something like the following: OLD: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates, following its translation logic, the Request-URI into one or more additional URIs. That is, the relay can create outgoing requests to one or more additional URIs. The translation operation is what creates the consent problem. NEW: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI into one or more additional URIs. Through this translation operation, the relay can create outgoing requests to one or more additional URIs, thus creating the consent problem. - Section 5.3, 5th paragraph, last sentence: OLD: The MESSAGE request also carry ... NEW: The MESSAGE request also carries ... - Section 5.9, 3rd paragraph, 1st sentence: OLD: ... this type of URI-list services behave in a slight different way... NEW: ... this type of URI-list services behave in a slightly different way... --NextPart_Webmail_9m3u9jl4l_4145_1161134707_0 Content-Type: text/html Content-Transfer-Encoding: 8bit
I'm posting this from my private email as my Outlook server has been down this afternoon and doesn't appear to be recovering this evening. 
 
Draft:  draft-ietf-sip-consent-framework-00.txt
Reviewer: Mary Barnes [mary.barnes@nortel.com]
Review Date: 17 October 2006
Review Deadline: 17 October 2006
Status: WGLC
 
Summary:  This draft is on the right track but has an issue and a few nits, described in the review.
 
Issues:
-------
- Section 4.3: I share the concern that Ben raised in his review with regards to this framework not making any recommendations about (or defining) a store-and-forward mechanism.  The off-line user issue is real and it would seem to be a large impediment to deployment of this functionality if there is not a recommendation for a must implement mechanism.  I don't expect this document to define the functionality since it is more general, but it does seem a requisite for this draft.
 
Nits:
------
- General: the term "Translation Logic" is used almost interchangeably with "Translation Operation", although only the latter term is defined in section 2. It would make this document a bit easier to follow, if a single term was used, provided they do mean the same thing.   Also, there is sometimes an "s" added to the use of the word "logic" - this likely is incorrect and should be changed if that term remains in the document.
 
-Section 3, 1st paragraph following Figure 1: the wording is a bit awkward and reads as if it's redundant, although it's not. Propose rewording to something like the following:
OLD:
   Thus, an essential aspect of a relay is that of translation.  When a
   relay receives a request, it translates, following its translation
   logic, the Request-URI into one or more additional URIs.  That is,
   the relay can create outgoing requests to one or more additional
   URIs.  The translation operation is what creates the consent problem.
NEW:
   Thus, an essential aspect of a relay is that of translation.  When a
   relay receives a request, it translates the Request-URI into one or
   more additional URIs. Through this translation operation,
   the relay can create outgoing requests to one or more additional
   URIs, thus creating the consent problem.
 
- Section 5.3, 5th paragraph, last sentence:
OLD:
  The MESSAGE request also carry ...
NEW:
  The MESSAGE request also carries ...
 
- Section 5.9, 3rd paragraph, 1st sentence:
OLD:
   ... this type of URI-list services behave in a slight different way...
NEW:
   ... this type of URI-list services behave in a slightly different way...
--NextPart_Webmail_9m3u9jl4l_4145_1161134707_0-- --===============1938550019== 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 --===============1938550019==-- From sip-bounces@ietf.org Wed Oct 18 04:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Mb-0004AP-A7; Wed, 18 Oct 2006 04:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6Ma-0004AA-2s for sip@ietf.org; Wed, 18 Oct 2006 04:01:20 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6MY-0002kd-LS for sip@ietf.org; Wed, 18 Oct 2006 04:01:20 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 10:01:15 +0200 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:01:15 +0200 Content-class: urn:content-classes:message Subject: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments MIME-Version: 1.0 Date: Wed, 18 Oct 2006 10:01:14 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 in-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22141200@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments Thread-Index: AcbyhujxfK1fOHsvQmC4/sFHWGrbrQAAkOwQ From: "Jesske, R" To: , X-OriginalArrivalTime: 18 Oct 2006 08:01:15.0180 (UTC) FILETIME=[95A78EC0:01C6F28B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dear all, With regard to the following section I have some concerns regarding the thought use of the P-Asserted-Identity. 4.3. Ingress Proxy .... If the identity is verified, the ingress proxy SHOULD insert a P-Asserted-ID header field containing the identity contained in the From header field of the request. The proxy SHOULD NOT remove the Identity and Identity- Info header fields. This allows for SIP networks where there are more than two administrative domains in a request path, and also allows for a UA to verify the signature on its own if it should desire.... This will violate the use of the From and P-Asserted-Identity header within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping with the PSTN. The P-Asserted-Identity is used as a public ID that is trusted. The From header is set by the user itself and is untrusted. So that there is the possibility to have two different identities within one INVITE. To equalise such identities within a B2BUA at the ingress even if the >From is also a now secure and trusted ID. Within the NGN this two identities are used for PBX services to present the main PBX number and a individual extension of the PBX. Also the deletion and re-inclusion is against the rules of the RFC3325. The destination domain is not allowed to change the identity of the originating domain. If such procedures will be done also charging and billing mechanisms used between domains will be violated. because the P-Asserted-Identity is the base identity of the origin domain on Billing and charging. Best Regards Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 18 05:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga7oV-0005Hk-7n; Wed, 18 Oct 2006 05:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga7oO-000520-9I for sip@ietf.org; Wed, 18 Oct 2006 05:34:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga7kN-0005Hg-Lj for sip@ietf.org; Wed, 18 Oct 2006 05:30:00 -0400 Received: by ug-out-1314.google.com with SMTP id 72so110943ugd for ; Wed, 18 Oct 2006 02:29:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UkpWnyKUt+0bTxWZZ5lM87vRnYS8vxhXA/6E7GU0xs7trPCvocdJwNToRV5uQPQFCr09k66R8UEh2Fh7YM9JgLuWSrcTQUdMNoyqTWGVfS7xodpLUr2Y2f8KMcH16q3ocVwJVFLCpgbaIe99IFvy6tSgCxljgqlLO6HppLjlfP8= Received: by 10.78.94.37 with SMTP id r37mr10416536hub; Wed, 18 Oct 2006 02:29:57 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Wed, 18 Oct 2006 02:29:57 -0700 (PDT) Message-ID: <60ac91480610180229x331bbed9qf9a1de5c2455354d@mail.gmail.com> Date: Wed, 18 Oct 2006 14:59:57 +0530 From: "Vasudeva M" To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] Recent List of all SIP headers in IANA registry X-BeenThere: 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="===============0867717290==" Errors-To: sip-bounces@ietf.org --===============0867717290== Content-Type: multipart/alternative; boundary="----=_Part_55179_8094067.1161163797705" ------=_Part_55179_8094067.1161163797705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I wanted to know whether there is ANY Central place to see currently IANA Registered SIP Headers... I checked out rfc3968 which gives all the SIP Headers in IANA Registry. The RFC was itself published in 2004. I could not find any other update to this RFC. I would like to get the Latest list of all the SIP Headers in the IANA registry and the corresponding RFCs/drafts... Any pointers would be really helpful. (google didn't help much though...) Thanks and Best Regards, Vasu ------=_Part_55179_8094067.1161163797705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

I wanted to know whether there is ANY Central place to see currently IANA Registered SIP Headers...
I checked out rfc3968 which gives all the SIP Headers in IANA Registry.
The RFC was itself published in 2004. I could not find any other update to this RFC.

I would like to get the Latest list of all the SIP Headers in the IANA registry and the corresponding RFCs/drafts...
Any pointers would be really helpful. (google didn't help much though...)

Thanks and Best Regards,
Vasu
------=_Part_55179_8094067.1161163797705-- --===============0867717290== 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 --===============0867717290==-- From sip-bounces@ietf.org Wed Oct 18 05:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga83P-0001ld-EG; Wed, 18 Oct 2006 05:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga83N-0001lY-Bx for sip@ietf.org; Wed, 18 Oct 2006 05:49:37 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga83K-0008LU-0V for sip@ietf.org; Wed, 18 Oct 2006 05:49:37 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9I9nLti027406; Wed, 18 Oct 2006 04:49:31 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Oct 2006 04:49:29 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Oct 2006 11:49:26 +0200 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] Recent List of all SIP headers in IANA registry Date: Wed, 18 Oct 2006 11:49:25 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918062566E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Recent List of all SIP headers in IANA registry Thread-Index: AcbymPI0vu1kd2NZQRiM9pRXzUP8JQAARdOA From: "Drage, Keith \(Keith\)" To: "Vasudeva M" , X-OriginalArrivalTime: 18 Oct 2006 09:49:26.0859 (UTC) FILETIME=[B2FF29B0:01C6F29A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 IANA registry is externally visible: =20 http://www.iana.org/numbers.html =20 and search for Session Initiation Protocol (SIP) Parameters Specifically they are at: http://www.iana.org/assignments/sip-parameters The purpose of RFC 3968 and RFC 3969 was to create these registries so IANA could continue to populate them from the IANA considerations sections of subsequent published documents (in accordance with the rules provided). Regards Keith ________________________________ From: Vasudeva M [mailto:vasudeva.manjunath@gmail.com]=20 Sent: 18 October 2006 10:30 To: sip@ietf.org Subject: [Sip] Recent List of all SIP headers in IANA registry =09 =09 Hi All, =09 I wanted to know whether there is ANY Central place to see currently IANA Registered SIP Headers... I checked out rfc3968 which gives all the SIP Headers in IANA Registry. The RFC was itself published in 2004. I could not find any other update to this RFC.=20 =09 I would like to get the Latest list of all the SIP Headers in the IANA registry and the corresponding RFCs/drafts... Any pointers would be really helpful. (google didn't help much though...) =09 Thanks and Best Regards,=20 Vasu =09 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 18 05:56:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga88D-0004b0-4R; Wed, 18 Oct 2006 05:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga88B-0004ao-Cx for sip@ietf.org; Wed, 18 Oct 2006 05:54:35 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga889-0000Wm-RU for sip@ietf.org; Wed, 18 Oct 2006 05:54:35 -0400 Received: by nf-out-0910.google.com with SMTP id n15so652517nfc for ; Wed, 18 Oct 2006 02:54:31 -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:references; b=diJUaHOX2GtKIkNmMePQCqkSEXU6yH/LzvngSTz15VYnurDdb5N2R/lhFz9J067aSjaW8cWq+AT4gRBI/SdjkVdlsKHKsOU9LFfi5FidStM+Pk0VllD2S/ektnwGAjNAz2ixv1oE9ap7/jnw3Bg9OvbL0dz99+0pXRXh1jEJn+0= Received: by 10.78.160.2 with SMTP id i2mr10365608hue; Wed, 18 Oct 2006 02:54:30 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Wed, 18 Oct 2006 02:54:30 -0700 (PDT) Message-ID: <60ac91480610180254t78dce64co1bb4be8cd1cb9330@mail.gmail.com> Date: Wed, 18 Oct 2006 15:24:30 +0530 From: "Vasudeva M" To: "Jonathan Rosenberg" Subject: Re: [Sip] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.txt In-Reply-To: <453548E5.2080707@cisco.com> MIME-Version: 1.0 References: <62B9B0847CC47543B6B3B5E26BD268E60E84F9F8@zrc2hxm2.corp.nortel.com> <453548E5.2080707@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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: , Content-Type: multipart/mixed; boundary="===============0007409956==" Errors-To: sip-bounces@ietf.org --===============0007409956== Content-Type: multipart/alternative; boundary="----=_Part_55407_4106965.1161165270506" ------=_Part_55407_4106965.1161165270506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Would it be OK if the references (RFC3968 and RFC3969) which lists currently IANA registered SIP headers(and URI parameters) are included in hitchhikers' guide ? (even though it does not extend/modify the SIP protocol.) Regards, Vasu On 10/18/06, Jonathan Rosenberg wrote: > > THanks for the comments, and apologies for the slow response. See below. > > Samir Srivastava wrote: > > > Hi, > > > > > > > > 1) Shouldn't we have reference to the open bugs in this guide in > > some form. Atleast a reference to bugzilla web site? > > That is not within the scope of this document. There is ongoing > discussion on what to do with those bugs, no conclusion yet. But this > document serves only to enumerate the SIP specifications. > > > > > > > > > 2) It refers the RFC 2976 for SIP INFO. Shouldn't it refer the RFC > > 2833 there. We may be widening its scope to media too.. > > INFO is an existing normative extension to SIP and so it is referenced. > That doesn't mean we are proposing it be used for DTMF; it just means > its an extension. RFC 2833 is not a SIP extension, it is an RTP > extension. So it is not included. > > > -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 > ------=_Part_55407_4106965.1161165270506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Would it be OK if the references (RFC3968 and RFC3969) which lists currently IANA registered SIP headers(and URI parameters) are included in hitchhikers' guide ? (even though it does not extend/modify the SIP protocol.)

Regards,
Vasu



On 10/18/06, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
THanks for the comments, and apologies for the slow response. See below.

Samir Srivastava wrote:

> Hi,
>
>
>
> 1)       Shouldn't we have reference to the open bugs in this guide in
> some form. Atleast a reference to bugzilla web site?

That is not within the scope of this document. There is ongoing
discussion on what to do with those bugs, no conclusion yet. But this
document serves only to enumerate the SIP specifications.

>
>
>
> 2)       It refers the RFC 2976 for SIP INFO. Shouldn't it refer the RFC
> 2833 there.  We may be widening its scope to media too..

INFO is an existing normative extension to SIP and so it is referenced.
That doesn't mean we are proposing it be used for DTMF; it just means
its an extension. RFC 2833 is not a SIP extension, it is an RTP
extension. So it is not included.


-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

------=_Part_55407_4106965.1161165270506-- --===============0007409956== 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 --===============0007409956==-- From sip-bounces@ietf.org Wed Oct 18 06:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8Cr-00013k-2a; Wed, 18 Oct 2006 05:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8Cp-00013a-GH for sip@ietf.org; Wed, 18 Oct 2006 05:59:23 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga8Cn-0001I6-EZ for sip@ietf.org; Wed, 18 Oct 2006 05:59:23 -0400 Received: by nf-out-0910.google.com with SMTP id n15so653956nfc for ; Wed, 18 Oct 2006 02:59:20 -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:references; b=ChEszGDDSLwl5iEoIC5qzxqPrJsQfO8OXc1KMnOHlGgg3d23STyPn1soRt4F+7qvXmeSVtEpmVNZHjuWywTUL8dZKLXr/NCC8o5bTH7+ehm9+1BbZ/8RMIUQbd+j4oTmKoN8m1xfN/+mg8+m8tZj5rbuJv1FrFr4J/NOfWvGFP4= Received: by 10.78.148.8 with SMTP id v8mr10402447hud; Wed, 18 Oct 2006 02:59:20 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Wed, 18 Oct 2006 02:59:19 -0700 (PDT) Message-ID: <60ac91480610180259u235cd17ai57a43322e321961f@mail.gmail.com> Date: Wed, 18 Oct 2006 15:29:20 +0530 From: "Vasudeva M" To: "Drage, Keith (Keith)" Subject: Re: [Sip] Recent List of all SIP headers in IANA registry In-Reply-To: <5D1A7985295922448D5550C94DE2918062566E@DEEXC1U01.de.lucent.com> MIME-Version: 1.0 References: <5D1A7985295922448D5550C94DE2918062566E@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Content-Type: multipart/mixed; boundary="===============0333494690==" Errors-To: sip-bounces@ietf.org --===============0333494690== Content-Type: multipart/alternative; boundary="----=_Part_55471_21905531.1161165560008" ------=_Part_55471_21905531.1161165560008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Keith, Thanks for the specific pointer... Regards, Vasu On 10/18/06, Drage, Keith (Keith) wrote: > > The IANA registry is externally visible: > > http://www.iana.org/numbers.html > > and search for Session Initiation Protocol (SIP) Parameters > > Specifically they are at: > > http://www.iana.org/assignments/sip-parameters > > The purpose of RFC 3968 and RFC 3969 was to create these registries so > IANA could continue to populate them from the IANA considerations > sections of subsequent published documents (in accordance with the rules > provided). > > Regards > > Keith > > > ________________________________ > > From: Vasudeva M [mailto:vasudeva.manjunath@gmail.com] > Sent: 18 October 2006 10:30 > To: sip@ietf.org > Subject: [Sip] Recent List of all SIP headers in IANA registry > > > Hi All, > > I wanted to know whether there is ANY Central place to see > currently IANA Registered SIP Headers... > I checked out rfc3968 which gives all the SIP Headers in IANA > Registry. > The RFC was itself published in 2004. I could not find any other > update to this RFC. > > I would like to get the Latest list of all the SIP Headers in > the IANA registry and the corresponding RFCs/drafts... > Any pointers would be really helpful. (google didn't help much > though...) > > Thanks and Best Regards, > Vasu > > > ------=_Part_55471_21905531.1161165560008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Keith,

Thanks for the specific pointer...

Regards,
Vasu

On 10/18/06, Drage, Keith (Keith) <drage@lucent.com > wrote:
The IANA registry is externally visible:

http://www.iana.org/numbers.html

and search for Session Initiation Protocol (SIP) Parameters

Specifically they are at:

http://www.iana.org/assignments/sip-parameters

The purpose of RFC 3968 and RFC 3969 was to create these registries so
IANA could continue to populate them from the IANA considerations
sections of subsequent published documents (in accordance with the rules
provided).

Regards

Keith


________________________________

        From: Vasudeva M [mailto:vasudeva.manjunath@gmail.com]
        Sent: 18 October 2006 10:30
        To: sip@ietf.org
        Subject: [Sip] Recent List of all SIP headers in IANA registry


        Hi All,

        I wanted to know whether there is ANY Central place to see
currently IANA Registered SIP Headers...
        I checked out rfc3968 which gives all the SIP Headers in IANA
Registry.
        The RFC was itself published in 2004. I could not find any other
update to this RFC.

        I would like to get the Latest list of all the SIP Headers in
the IANA registry and the corresponding RFCs/drafts...
        Any pointers would be really helpful. (google didn't help much
though...)

        Thanks and Best Regards,
        Vasu



------=_Part_55471_21905531.1161165560008-- --===============0333494690== 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 --===============0333494690==-- From sip-bounces@ietf.org Wed Oct 18 06:28:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8br-00083Y-LZ; Wed, 18 Oct 2006 06:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8bh-0007uO-V7 for sip@ietf.org; Wed, 18 Oct 2006 06:25:06 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga8a5-0003gJ-6d for sip@ietf.org; Wed, 18 Oct 2006 06:23:26 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 12:23:21 +0200 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 12:23:21 +0200 Content-class: urn:content-classes:message Subject: AW: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) MIME-Version: 1.0 Date: Wed, 18 Oct 2006 12:23:20 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <85108216918A984C8C60172D7C84770A56F7AC@S4DE8PSAAGO.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 in-reply-to: <45356CD9.4040801@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) Thread-Index: AcbyR9xhIwdB3JJnQWScgrHOHX73SwAVyAow From: "Jesske, R" To: , X-OriginalArrivalTime: 18 Oct 2006 10:23:21.0266 (UTC) FILETIME=[6F990920:01C6F29F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, dwing@cisco.com, jon.peterson@neustar.biz X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Lastly, if P-A-ID value is used in some context, changing the value > may cause some problem as well(Assuming P-A-ID was there but a > different value from FROM value > verifier after verification succeeds > change the P-A-ID value to that of FROM). As I commented in an other mail. There should be never a change of the = P-Asserted-Identity. That is not the intension of the = P-Asserted-Identity to be updated because the connected-ID in the From = was verified by some mechanism. Many Services like PBX, Forwarding, billing in IMS are based on the = P-Asserted-Identity as it is now and assumes that it will not be = changed. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Shida Schubert [mailto:shida@ntt-at.com]=20 > Gesendet: Mittwoch, 18. Oktober 2006 01:53 > An: Paul Kyzivat > Cc: Cullen Jennings; SIP; Elwell, John; Jon Peterson; Dan Wing > Betreff: Re: [Sip] RE: Rejecting connected identity (was RE:=20 > draft-ietf-si p-connecte d-id entity-01 comments) >=20 >=20 >=20 > Although using P-A-ID may look like a good approach for this, > I don't know if it's really a good idea as it seems to change the > semantics of P-A-ID. >=20 > Also, it may generates some issues when P-A-ID already exists > in the message along with connected-identity. >=20 > Following illustrates potential problems. >=20 > connected-id(FROM): carol@b.com > P-A-ID: carol@b.com >=20 > Now, following the proposal by John when Case 2 is deployed, > and assuming the verification of identity failed, it will=20 > still forward > the message as it is if we allow Case 2. When UAS receives the request > it will see both the identity-info/header and P-A-ID with the value > equivalent to the value in the FROM header.. If UAS has no ability > to verify the signature itself, it will assume that the verification > worked. P-A-ID looks like a good place to indicate the success of > the verification but it might need something else. >=20 > As for Cullen's comments. I agree with Paul here, if the security > policy at the verification side would allow request without identity, > it should forward the request even if the verification fails. >=20 > Lastly, if P-A-ID value is used in some context, changing the value > may cause some problem as well(Assuming P-A-ID was there but a > different value from FROM value > verifier after verification succeeds > change the P-A-ID value to that of FROM). >=20 > Regards > Shida >=20 > Paul Kyzivat wrote: > > > > > > Cullen Jennings wrote: > >> > >> I'm generally on board with things like you are suggesting=20 > below and > >> what is suggested in draft-rosenberg-sip-identity-coexistence. > >> However, I want to think very carefully about the security=20 > properties > >> of not rejecting things that failed based on security properties - > >> I'm not sure what I think of this yet. > >> > >> Any time you allow a security action that failed to=20 > continue sending > >> the request downstream, you run the risk that something=20 > further down > >> stream assumes that the security action worked because it must have > >> happened upstream. Clearly from a security point of view=20 > it would be > >> better not to have upstream elements do the security=20 > validation for a > >> downstream element but we did decide long ago that when doing > >> Identity we were going to allow for this so that we could migrate > >> from UAs that do not support Identity to system that does. > >> > >> So let me flip this around the other way and ask - do we=20 > really need > >> to allow for a request that failed verification to not result in an > >> error?=20 > > > > I think the poster child for this is when the error is 437=20 > Unsupported > > Certificate. > > > > In this case the caller may be trapped. It has an identity=20 > service it > > can't control, that unconditionally adds an identity. And then the > > callee has an authentication verifier in front of it. As=20 > things stand, > > that verifier is required to reject requests with certs it doesn't > > understand, even in cases where it will permit requests with no > > identity at all. > > > > Paul > > > >> Are there use cases where the verification would fail and we really > >> do want to continue with the message? If these cases would only > >> happen in a fairly broken system, then it might not be worth the > >> security problems they would cause. I don't know what I think but I > >> am interested in where we might need this and if there=20 > might be other > >> ways to skin the cat in those situations. > >> > >> Cullen > >> > >> > >> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > >> > >>> John, > >>> > >>> What you outline below is exactly what I had in mind. > >>> > >>> Paul > >>> > >>> Elwell, John wrote: > >>>> Paul, > >>>> Dan Wing made a suggestion that P-Asserted-Identity=20 > would fulfil your > >>>> requirement. I guess it would work like this. > >>>> A Verifier not located at the UAS would attempt to verify the > >>>> signature in > >>>> the Identity header field. > >>>> - Case A - verification succeeds. The Verifier inserts into the > >>>> forwarded > >>>> request a P-Asserted-Identity header field containing=20 > the verified > >>>> URI (from > >>>> the From header field) in the forwarded request. The Identity and > >>>> Identity-Info header fields will still be present and=20 > available should > >>>> another verifier be encountered downstream. > >>>> - Case B - verification fails but request not rejected. The > >>>> verifier is > >>>> unable to verify (e.g., because it can't dereference the URL) but > >>>> according > >>>> to policy does not reject the request. It simply forwards the > >>>> request as is. > >>>> If there is a further verifier downstream, that too can=20 > attempt to > >>>> verify > >>>> the signature. > >>>> - Case C - verification fails but request is rejected.=20 > The verifier is > >>>> unable to verify (e.g., bad signature) and according to policy it > >>>> rejects > >>>> the request. > >>>> A UAS that does not contain a verifier can simply use > >>>> P-Asserted-Identity, > >>>> if present. > >>>> This seems to have some synergy with > >>>> draft-rosenberg-sip-identity-coexistence. In fact the=20 > relaxation of > >>>> rules > >>>> concerning rejection by a verifier that is unable to verify a > >>>> signature > >>>> might be beneficial to that proposal. > >>>> I will omit discussion of the mechanics of documentation until I > >>>> see what > >>>> reaction there is to the technical proposal. > >>>> John > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October > >>>>> 2006 13:54 > >>>>> To: Elwell, John > >>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>> > >>>>> > >>>>> > >>>>> Elwell, John wrote: > >>>>>> Paul, > >>>>>> > >>>>>> Your message arrived just after I had submitted 02, so your > >>>>> comments are not > >>>>>> taken into account in that version. However, I felt it was > >>>>> useful to get 02 > >>>>>> out as a baseline for further discussion. > >>>>> Sure. I too am interested in seeing other inputs on=20 > this subject. > >>>>> > >>>>>> It seems the remaining issue is whether to add an explicit > >>>>> indication of > >>>>>> removal of the Identity header field by a verifier that has > >>>>> been unable to > >>>>>> verify the signature. Whilst this may make sense, I am > >>>>> concerned it starts > >>>>>> to go beyond the scope of connected-identity, so I=20 > would like other > >>>>>> opinions, especially from the chairs and from the authors > >>>>> of Identity. > >>>>> > >>>>> Rather than adding something to indicate that identity has been > >>>>> *removed* due to failure to verify, I am advocating adding > >>>>> something to indicate that verification has *succeeded*, while > >>>>> leaving the identity header in place. In this way, a downstream > >>>>> element may *either* trust the info added by the verifier or do > >>>>> its own verification of the identity header. > >>>>> > >>>>> Of course this is only significant if the verifier is doing work > >>>>> for downstream elements, and not for itself. > >>>>> > >>>>> Paul > >>>>> > >>>>>> John > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent:=20 > 05 October > >>>>>>> 2006 16:29 > >>>>>>> To: Elwell, John > >>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Elwell, John wrote: > >>>>>>>> Paul, > >>>>>>>> > >>>>>>>> So your proposal is that the connected-identity RFC should > >>>>>>> update RFC 4474 > >>>>>>>> to somehow relax rules at a verifier. Correct? > >>>>>>> Yeah, I think so. > >>>>>>> > >>>>>>>> So the next question concerns the way in which these > >>>>> rules should be > >>>>>>>> relaxed. One problem with the verifier not being located at > >>>>>>> the UAS but at > >>>>>>>> some proxy is that the UAS might be configured always to > >>>>>>> trust identities > >>>>>>>> received in requests via the verifier's proxy if an > >>>>>>> Identity header field is > >>>>>>>> present, on the assumption that the signature has been > >>>>>>> checked by the > >>>>>>>> verifier. Therefore it sounds like the verifier, if it does > >>>>>>> not reject a > >>>>>>>> request with a bad signature, should remove the Identity > >>>>>>> header field (and > >>>>>>>> also Identity-Info) before forwarding the request towards > >>>>>>> the target. > >>>>>>> > >>>>>>> (I think I have seen someone propose combining the use of > >>>>>>> Identity and P-Asserted-Identity, though I don't recall the > >>>>>>> details, or which draft it was. So what I am about to=20 > say might > >>>>>>> bear no > >>>>> relationship to that.) > >>>>>>> I could see how Identity might be used between trust > >>>>> domains, while > >>>>>>> P-Asserted-Identity is used within a trust domain. In=20 > that case, > >>>>>>> a verifier might run at the entry point to a trust=20 > domain and if > >>>>>>> verification succeeds, insert a P-Asserted-Identity=20 > header with > >>>>>>> a corresponding identity. It then might, or might not, remove > >>>>>>> the Identity header. Recipients within the trust domain could > >>>>>>> then use P-Asserted-Identity as the source of=20 > identity info. (In > >>>>>>> this scenario, an identity header would only be added to > >>>>>>> requests when they leave the trust domain.) > >>>>>>> > >>>>>>> In this kind of environment, it is only necessary for the > >>>>> verifier to > >>>>>>> omit the P-Asserted-Identity header when verification fails. > >>>>>>> > >>>>>>>> Under what conditions should a verifier remove an Identity > >>>>>>> header field > >>>>>>>> rather than rejecting with 436/437/438? My inclination > >>>>>>> would be to leave it > >>>>>>>> as a matter of policy as far as the update to RFC 4474 is > >>>>>>> concerned, and > >>>>>>>> then make more precise statements concerning=20 > mid-dialog requests. > >>>>>>>> Alternatively the update to RFC 4474 could just relax the > >>>>> rules for > >>>>>>>> mid-dialog requests. I think there is some merit in > >>>>>>> relaxing the rules in > >>>>>>>> general, because otherwise there might be situations where > >>>>>>> a legitimate > >>>>>>>> caller cannot establish a call because an Authentication > >>>>>>> Service (outside > >>>>>>>> the UAC's control) is inserting an unverifiable signature > >>>>> (e.g., in > >>>>>>>> Identity-Info placing a URL that the Verifier cannot > >>>>>>> dereference for some > >>>>>>>> reason). > >>>>>>> What you say sounds reasonable to me. > >>>>>>> > >>>>>>> There is however some risk to having a verifier remove > >>>>> identity. The > >>>>>>> problem would be when there are potentially multiple > >>>>> verifiers that > >>>>>>> don't trust one another. If an early one removes the > >>>>> header, then it > >>>>>>> prevents a subsequent verifier from doing its own=20 > verification. > >>>>>>> > >>>>>>> This could come up if a request transits a domain on=20 > the way to > >>>>>>> another domain. Each domain may wish to do its own=20 > verification. > >>>>>>> > >>>>>>> That is an advantage to having the verifier add=20 > something to the > >>>>>>> request to indicate the result of its verification. > >>>>>>> > >>>>>>>> One consequence of the Verifier being separated from the > >>>>>>> UAS is that we > >>>>>>>> don't want to rely on stateful behaviour at the Verifier or > >>>>>>> its proxy (for > >>>>>>>> similar reasons that you cited for the Authentication > >>>>>>> Service earlier). So > >>>>>>>> for mid-dialog requests we would need to mandate, or at > >>>>>>> least recommend, > >>>>>>>> that 436/437/438 should not be sent. > >>>>>>> Right. > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>>> John > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 > >>>>>>>>> October 2006 01:44 > >>>>>>>>> To: Elwell, John > >>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Elwell, John wrote: > >>>>>>>>>> Thinking further on this, perhaps there is a 4th way: > >>>>>>>>>> > >>>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>>>>>>> 436, 437 or 438, > >>>>>>>>>> then it MUST NOT invoke the verifier for a=20 > subsequent request > >>>>>>>>> This assumes that the verifier is invoked by the UAS, and > >>>>>>> not by some > >>>>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier > >>>>>>>>> in a proxy before the UAS? This rule would forbid that, > >>>>>>>>> because it would cause that proxy to be call stateful. > >>>>>>>>> > >>>>>>>>> I think it would just be better to update the RFC,=20 > even though > >>>>>>>>> that is a bit more trouble than not to. > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> on the same > >>>>>>>>>> dialog unless the From header field URI has changed, and in > >>>>>>>>> such cases > >>>>>>>>>> SHOULD NOT make use of the unverified connected-identity. > >>>>>>>>> Then a UAC, on > >>>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>>>>>>> This would allow > >>>>>>>>>> business as usual on this dialog (but without the benefit > >>>>>>>>> of connected > >>>>>>>>>> identity, therefore no worse than at present). It avoids > >>>>>>>>> any change to RFC > >>>>>>>>>> 4474, because verification is optional anyway. > >>>>>>>>>> > >>>>>>>>>> Would this work? > >>>>>>>>>> > >>>>>>>>>> John > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 > >>>>>>>>>>> To: Cullen Jennings; Jon Peterson > >>>>>>>>>>> Cc: SIP; Paul Kyzivat > >>>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: > >>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>>> > >>>>>>>>>>> Cullen, Jon, > >>>>>>>>>>> > >>>>>>>>>>> In case you missed this (it wasn't addressed directly to > >>>>>>>>>>> you), I would greatly appreciate an opinion from=20 > each of you > >>>>>>>>>>> on this remaining issue in connected-identity. Just to > >>>>>>>>>>> summarise, RFC 4474 leaves it up to policy=20 > whether to return > >>>>>>>>>>> a 428 response if Identity is missing, but mandates the > >>>>>>>>>>> sending of a 436, 437 or 438 response for certain errors > >>>>>>>>>>> arising while verifying the signature. It seems=20 > that for mid > >>>>>>>>>>> dialog requests this behaviour could be harmful. What does > >>>>>>>>>>> the UAC for the mid dialog request do if it receives 436, > >>>>>>>>>>> 437 or 438? If the mid-dialog request was solely for the > >>>>>>>>>>> purpose of connected identity, it can give up and=20 > allow the > >>>>>>>>>>> call to continue as is. But if the request was for some > >>>>>>>>>>> other purpose (e.g., renegotiating the session because of > >>>>>>>>>>> hold, say, or session timer refresh), the UAC really wants > >>>>>>>>>>> it to work. For the normal case where the Authentication > >>>>>>>>>>> Service is at a proxy, not at the UAC, the UAC=20 > cannot force > >>>>>>>>>>> the Authentication Service to refrain from putting this > >>>>>>>>>>> unverifiable signature in the mid-dialog request, so any > >>>>>>>>>>> attempts to repeat the request would most likely be doomed > >>>>>>>>>>> to getting the same response. > >>>>>>>>>>> > >>>>>>>>>>> It seems there are three things we could do, none very > >>>>>>> attractive: > >>>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC > >>>>>>>>>>> 4474 for a verifier by softening the requirements for > >>>>>>>>>>> sending 436, 437 and 438 in response to=20 > mid-dialog requests. > >>>>>>>>>>> But then a mid-dialog request from a rogue source would be > >>>>>>>>>>> accepted. > >>>>>>>>>>> 2. Say that the Authentication Service should omit the > >>>>>>>>>>> signing of mid-dialog requests if a previous attempt has > >>>>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness > >>>>>>>>> at the AS. > >>>>>>>>>>> 3. Accept the fact the mid-dialog requests can=20 > fail in this > >>>>>>>>>>> way and therefore things like session refresh and session > >>>>>>>>>>> renegotiation cannot be done, probably resulting in call > >>>>>>>>>>> failure. Sounds bad, but it is no different from=20 > an initial > >>>>>>>>>>> INVITE request, where there is nothing the UAC=20 > can do if the > >>>>>>>>>>> AS inserts an Identity header that gets rejected with 436, > >>>>>>>>> 437 or 438. > >>>>>>>>>>> John > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>>>> September 2006 19:26 > >>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>>>> > >>>>>>>>>>>> John, > >>>>>>>>>>>> > >>>>>>>>>>>> I want to hear what others, especially Jon and=20 > Cullen, have > >>>>>>>>>>>> to say about this. > >>>>>>>>>>>> > >>>>>>>>>>>> It is of some concern to me that a call might fail > >>>>>>>>> because of some > >>>>>>>>>>>> problem with the identity mechanism when the same call > >>>>>>> might have > >>>>>>>>>>>> succeeded in the absence of any identity. > >>>>>>>>>>>> > >>>>>>>>>>>> But possibly the solution to this is policy in the > >>>>>>>>>>>> implementation of the verifier. What to do in the case of > >>>>>>>>>>>> the conditions that > >>>>>>>>>>> lead to these > >>>>>>>>>>>> errors could be configurable in the verifier: either to > >>>>>>>>>>> generate the > >>>>>>>>>>>> error or simply to remove the identity info from the > >>>>>>>>>>> message. And the > >>>>>>>>>>>> policy could conceivably vary based on attributes of the > >>>>>>>>>>>> message, such as whether it is in-dialog or not. > >>>>>>>>>>>> > >>>>>>>>>>>> Does it require a change to 4474 to permit that kind > >>>>> of policy? > >>>>>>>>>>>> It would be annoying if the end user had no control over > >>>>>>>>>>>> the insertion and verification of identity, and=20 > it resulted > >>>>>>>>>>>> in calls failing that the user would like to=20 > permit. But I > >>>>>>>>>>>> suppose that is itself > >>>>>>> a policy > >>>>>>>>>>>> decision. There are certainly enterprises that want to > >>>>>>>>>>>> exert that kind of control over what users are=20 > permitted to > >>>>>>>>>>>> do. > >>>>>>>>>>>> > >>>>>>>>>>>> Paul > >>>>>>>>>>>> > >>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>> Paul, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I agree with most of your points, and on=20 > reflection I think > >>>>>>>>>>>> I agree that the > >>>>>>>>>>>>> solution has to be with the verifier. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think RFC 4474 is not a problem as far as=20 > sending a 428 > >>>>>>>>>>>> 'Use Identity > >>>>>>>>>>>>> Header' response is concerned, because that is left to > >>>>>>>>>>>> policy, so we could > >>>>>>>>>>>>> say in connected-identity that policy should be to not > >>>>>>> send 428. > >>>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>>>>>>> because RFC 4474 says > >>>>>>>>>>>>> that they MUST be sent under respective conditions. > >>>>>>>>>>>> Interestingly, though, > >>>>>>>>>>>>> there are other failure scenarios that can=20 > arise from the > >>>>>>>>>>>> procedures of > >>>>>>>>>>>>> section 6 of RFC 4474 for which no normative=20 > statement is > >>>>>>>>>>>> given on how to > >>>>>>>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>>>>>>> authoritative for the > >>>>>>>>>>>>> domain. > >>>>>>>>>>>>> > >>>>>>>>>>>>> So one way to solve the present problem would be for the > >>>>>>>>>>>> connected-identity > >>>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474=20 > in the case > >>>>>>>>>>>> of mid-dialog > >>>>>>>>>>>>> requests. I guess this would mean that it would=20 > update RFC > >>>>>>>>>>>> 4474 as well as > >>>>>>>>>>>>> updating RFC 3261. But I don't like this,=20 > because it seems > >>>>>>>>>>>> to remove some of > >>>>>>>>>>>>> the security properties of RFC 4474. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>>>>>>> responses will be sent, > >>>>>>>>>>>>> and failure to verify a signature will=20 > therefore result in > >>>>>>>>>>>> inability to > >>>>>>>>>>>>> process the UPDATE or re-INVITE request, and=20 > hence if the > >>>>>>>>>>> UPDATE or > >>>>>>>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>>>>>>> session timer refresh > >>>>>>>>>>>>> or modifying the session, that action will=20 > fail. Then the > >>>>>>>>>>>> call will fail (in > >>>>>>>>>>>>> the case of inability to refresh the session timer) or > >>>>>>>>> the session > >>>>>>>>>>>>> modification will fail. I guess this is=20 > somewhat analogous > >>>>>>>>>>>> to caller ID > >>>>>>>>>>>>> verification failure in an INVITE request - it is > >>>>>>>>>>>> impossible to establish a > >>>>>>>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>>>>>>> ability to rectify the > >>>>>>>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>>>>>>> Authentication Service > >>>>>>>>>>>>> that puts a rogue Identity header field in=20 > every request. > >>>>>>>>>>>> In the connected > >>>>>>>>>>>>> identity case, the only difference is that the call is > >>>>>>>>>>>> already established > >>>>>>>>>>>>> but is likely to fail if verification fails. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>>>>>>> wrong source, then > >>>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct > >>>>>>>>>>>> thing to do, and > >>>>>>>>>>>>> overriding the verification procedures of RFC 4474 would > >>>>>>>>>>>> indeed be the wrong > >>>>>>>>>>>>> thing to do. So perhaps we just have to accept=20 > that these > >>>>>>>>>>>> response codes can > >>>>>>>>>>>>> be received and will lead to failure. > >>>>>>>>>>>>> > >>>>>>>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>>>>>>> sending a 428 and > >>>>>>>>>>>>> accept the consequences of other responses that the > >>>>>>>>>>>> verifier might send. > >>>>>>>>>>>>> John > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 > >>>>>>>>>>>>>> September 2006 15:13 > >>>>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>>>>> From: Cullen Jennings=20 > [mailto:fluffy@cisco.com] When an > >>>>>>>>>>>>>>>> Update is sent. Are there any conditions > >>>>>>> under which > >>>>>>>>>>>>>>>> it might be rejected. Bad identity for=20 > example. I think > >>>>>>>>>>>>>>>> that > >>>>>>>>>>>> might need a > >>>>>>>>>>>>>>>> little discussion and also what the UA does=20 > when it sends > >>>>>>>>>>>>>> an update > >>>>>>>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>>>>>>> situation where it is > >>>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>>>>>>> purposes such as > >>>>>>>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>>>>>>> because connected > >>>>>>>>>>>>>>> identity fails. > >>>>>>>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a=20 > mid-dialog request > >>>>>>>>>>>>>> with 428 'Use > >>>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>>> I'm not sure about this. At the least I think this > >>>>> one needs > >>>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the > >>>>>>>>>>>>>> conditions when > >>>>>>>>>>>> it can be > >>>>>>>>>>>>>> violated. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>>>>>>> challenge on an > >>>>>>>>>>>>>> in-dialog request. In some cases it is the right > >>>>> thing to do. > >>>>>>>>>>>>>> A UA that imposes such a requirement will be > >>>>> limited in what > >>>>>>>>>>>>>> it can do, but that may still be right in some cases. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>>>>>>> Identity header field > >>>>>>>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>>>>>>> dialog has resulted in > >>>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported=20 > Certificate' or > >>>>>>>>>>>>>> 438 'Invalid > >>>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>>> This requirement would force the=20 > authentication service to > >>>>>>>>>>>> be dialog > >>>>>>>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>>>>>>> back into the > >>>>>>>>>>>>>> sender of the request. This may require a way=20 > for the UAC > >>>>>>>>>>>> to tell the > >>>>>>>>>>>>>> authentication service not to act. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog=20 > request that > >>>>>>>>>>>>>> results in one of > >>>>>>>>>>>>>>> these responses if the mid-dialog request was=20 > not solely > >>>>>>>>>>>>>> for the purpose of > >>>>>>>>>>>>>>> connected identity. If solely for the purpose=20 > of connected > >>>>>>>>>>>>>> identity there is > >>>>>>>>>>>>>>> no point in repeating it, so I will say=20 > "SHOULD NOT take > >>>>>>>>>>>> any further > >>>>>>>>>>>>>>> action". > >>>>>>>>>>>>>> This seems wrong to me. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think that the remedy to these is in the=20 > verifier. The > >>>>>>>>>>>>>> purpose of the verifier is ultimately to drive an > >>>>>>>>>>>>>> authorization > >>>>> decision. If > >>>>>>>>>>>>>> authorization would succeed in the absence of the > >>>>>>>>>>>> identity, then the > >>>>>>>>>>>>>> request should be permitted to continue as if the > >>>>>>>>>>>>>> identity was not present. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Unfortunately this would seem to require a revision to > >>>>>>>>>>>>>> 4474 even though the paint is hardly dry on it. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If this is done, then there is no need of a=20 > mechanism to > >>>>>>>>>>> cause the > >>>>>>>>>>>>>> authentication service *not* to authenticate.=20 > If this is > >>>>>>>>>>>> *not* done, > >>>>>>>>>>>>>> then that need remains, which will still require a > >>>>>>>>>>> change to 4474. > >>>>>>>>>>>>>> Paul > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> Sip mailing list=20 > https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>>>>>>> This list is for NEW development of the core=20 > SIP 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 > > > > >=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 Wed Oct 18 09:12:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBAc-00014f-8K; Wed, 18 Oct 2006 09:09:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBAa-00014a-Il for sip@ietf.org; Wed, 18 Oct 2006 09:09:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBAU-0003Sy-Sk for sip@ietf.org; Wed, 18 Oct 2006 09:09:16 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 06:09:11 -0700 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 k9ID9ALD000962; Wed, 18 Oct 2006 09:09:10 -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 k9ID99DO003031; Wed, 18 Oct 2006 09:09: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); Wed, 18 Oct 2006 09:09:09 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:09:09 -0400 Message-ID: <45362774.6030407@cisco.com> Date: Wed, 18 Oct 2006 09:09:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-si p-connecte d-id entity-01 comments) References: <50B1CBA96870A34799A506B2313F26670A0DCB98@ntht201e.siemenscomms.co.uk> <452B9E1C.4030804@cisco.com> <6CDE0838-1170-443A-B4E9-CAB528221F58@cisco.com> <452D223A.8080403@cisco.com> <45356CD9.4040801@ntt-at.com> In-Reply-To: <45356CD9.4040801@ntt-at.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 13:09:09.0148 (UTC) FILETIME=[98FF5DC0:01C6F2B6] DKIM-Signature: a=rsa-sha1; q=dns; l=28748; t=1161176950; x=1162040950; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-si=0A=20p-connecte=20d-id=20entity-01=20comments) |To:shida@ntt-at.com; X=v=3Dcisco.com=3B=20h=3DFjuVp4POp00F1NQo6+iBgv4tYm8=3D; b=f1gP+zj4luOJJRRFCZyCrMDzg2gaTdDvDjjupjA+nOiME8QKw0z3Yi6d409QXutqrvuqXISZ +/DmBbMvcTmh9Vn9pEPZr5T1EcRjSpycUx2qISARcw/7dEWD5912XDoI; 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: f5e3f76ec5b90a46b9b8bc53da20ed8e Cc: Cullen Jennings , SIP , "Elwell, John" , Jon Peterson , 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 Shida Schubert wrote: > Although using P-A-ID may look like a good approach for this, > I don't know if it's really a good idea as it seems to change the > semantics of P-A-ID. I don't think this *is* changing the semantics of P-A-ID. The semantics are very simple: something in the trust domain determines the identity of the message and inserts to header for the benefit of others in the trust domain. The entity doing the assertion has full latitude about how it determines the identity it asserts. What this is doing is providing a new way to make that determination. The new way may not be appropriate in all environments, and that's fine. > Also, it may generates some issues when P-A-ID already exists > in the message along with connected-identity. That part needs to be clarified. > Following illustrates potential problems. > > connected-id(FROM): carol@b.com > P-A-ID: carol@b.com > > Now, following the proposal by John when Case 2 is deployed, > and assuming the verification of identity failed, it will still forward > the message as it is if we allow Case 2. I guess here you are assuming: - the P-A-ID was present before the verifier got the message - the verifier leaves it in the message when verification fails These are assumptions about the interaction of preexisting P-A-ID and connected identity verification. There is an issue there, but there are other possible answers to it. > When UAS receives the request > it will see both the identity-info/header and P-A-ID with the value > equivalent to the value in the FROM header.. If UAS has no ability > to verify the signature itself, it will assume that the verification > worked. P-A-ID looks like a good place to indicate the success of > the verification but it might need something else. IMO the presence of the P-A-ID is not evidence that the verification worked. It is merely in indication that someone in the trust domain asserted this identity. It could be because the verification of the Identity worked, or because some other kind of authentication worked, or it could be because some bogus party within the trust domain lied. If you choose to trust the P-A-ID, it means you choose to believe in the trust model. Nothing more. > As for Cullen's comments. I agree with Paul here, if the security > policy at the verification side would allow request without identity, > it should forward the request even if the verification fails. > > Lastly, if P-A-ID value is used in some context, changing the value > may cause some problem as well(Assuming P-A-ID was there but a > different value from FROM value > verifier after verification succeeds > change the P-A-ID value to that of FROM). > > Regards > Shida > > Paul Kyzivat wrote: >> >> Cullen Jennings wrote: >>> I'm generally on board with things like you are suggesting below and >>> what is suggested in draft-rosenberg-sip-identity-coexistence. >>> However, I want to think very carefully about the security properties >>> of not rejecting things that failed based on security properties - >>> I'm not sure what I think of this yet. >>> >>> Any time you allow a security action that failed to continue sending >>> the request downstream, you run the risk that something further down >>> stream assumes that the security action worked because it must have >>> happened upstream. Clearly from a security point of view it would be >>> better not to have upstream elements do the security validation for a >>> downstream element but we did decide long ago that when doing >>> Identity we were going to allow for this so that we could migrate >>> from UAs that do not support Identity to system that does. >>> >>> So let me flip this around the other way and ask - do we really need >>> to allow for a request that failed verification to not result in an >>> error? >> I think the poster child for this is when the error is 437 Unsupported >> Certificate. >> >> In this case the caller may be trapped. It has an identity service it >> can't control, that unconditionally adds an identity. And then the >> callee has an authentication verifier in front of it. As things stand, >> that verifier is required to reject requests with certs it doesn't >> understand, even in cases where it will permit requests with no >> identity at all. >> >> Paul >> >>> Are there use cases where the verification would fail and we really >>> do want to continue with the message? If these cases would only >>> happen in a fairly broken system, then it might not be worth the >>> security problems they would cause. I don't know what I think but I >>> am interested in where we might need this and if there might be other >>> ways to skin the cat in those situations. >>> >>> Cullen >>> >>> >>> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: >>> >>>> John, >>>> >>>> What you outline below is exactly what I had in mind. >>>> >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> Paul, >>>>> Dan Wing made a suggestion that P-Asserted-Identity would fulfil your >>>>> requirement. I guess it would work like this. >>>>> A Verifier not located at the UAS would attempt to verify the >>>>> signature in >>>>> the Identity header field. >>>>> - Case A - verification succeeds. The Verifier inserts into the >>>>> forwarded >>>>> request a P-Asserted-Identity header field containing the verified >>>>> URI (from >>>>> the From header field) in the forwarded request. The Identity and >>>>> Identity-Info header fields will still be present and available should >>>>> another verifier be encountered downstream. >>>>> - Case B - verification fails but request not rejected. The >>>>> verifier is >>>>> unable to verify (e.g., because it can't dereference the URL) but >>>>> according >>>>> to policy does not reject the request. It simply forwards the >>>>> request as is. >>>>> If there is a further verifier downstream, that too can attempt to >>>>> verify >>>>> the signature. >>>>> - Case C - verification fails but request is rejected. The verifier is >>>>> unable to verify (e.g., bad signature) and according to policy it >>>>> rejects >>>>> the request. >>>>> A UAS that does not contain a verifier can simply use >>>>> P-Asserted-Identity, >>>>> if present. >>>>> This seems to have some synergy with >>>>> draft-rosenberg-sip-identity-coexistence. In fact the relaxation of >>>>> rules >>>>> concerning rejection by a verifier that is unable to verify a >>>>> signature >>>>> might be beneficial to that proposal. >>>>> I will omit discussion of the mechanics of documentation until I >>>>> see what >>>>> reaction there is to the technical proposal. >>>>> John >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October >>>>>> 2006 13:54 >>>>>> To: Elwell, John >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>> >>>>>> >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Paul, >>>>>>> >>>>>>> Your message arrived just after I had submitted 02, so your >>>>>> comments are not >>>>>>> taken into account in that version. However, I felt it was >>>>>> useful to get 02 >>>>>>> out as a baseline for further discussion. >>>>>> Sure. I too am interested in seeing other inputs on this subject. >>>>>> >>>>>>> It seems the remaining issue is whether to add an explicit >>>>>> indication of >>>>>>> removal of the Identity header field by a verifier that has >>>>>> been unable to >>>>>>> verify the signature. Whilst this may make sense, I am >>>>>> concerned it starts >>>>>>> to go beyond the scope of connected-identity, so I would like other >>>>>>> opinions, especially from the chairs and from the authors >>>>>> of Identity. >>>>>> >>>>>> Rather than adding something to indicate that identity has been >>>>>> *removed* due to failure to verify, I am advocating adding >>>>>> something to indicate that verification has *succeeded*, while >>>>>> leaving the identity header in place. In this way, a downstream >>>>>> element may *either* trust the info added by the verifier or do >>>>>> its own verification of the identity header. >>>>>> >>>>>> Of course this is only significant if the verifier is doing work >>>>>> for downstream elements, and not for itself. >>>>>> >>>>>> Paul >>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 05 October >>>>>>>> 2006 16:29 >>>>>>>> To: Elwell, John >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Elwell, John wrote: >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> So your proposal is that the connected-identity RFC should >>>>>>>> update RFC 4474 >>>>>>>>> to somehow relax rules at a verifier. Correct? >>>>>>>> Yeah, I think so. >>>>>>>> >>>>>>>>> So the next question concerns the way in which these >>>>>> rules should be >>>>>>>>> relaxed. One problem with the verifier not being located at >>>>>>>> the UAS but at >>>>>>>>> some proxy is that the UAS might be configured always to >>>>>>>> trust identities >>>>>>>>> received in requests via the verifier's proxy if an >>>>>>>> Identity header field is >>>>>>>>> present, on the assumption that the signature has been >>>>>>>> checked by the >>>>>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>>>>> not reject a >>>>>>>>> request with a bad signature, should remove the Identity >>>>>>>> header field (and >>>>>>>>> also Identity-Info) before forwarding the request towards >>>>>>>> the target. >>>>>>>> >>>>>>>> (I think I have seen someone propose combining the use of >>>>>>>> Identity and P-Asserted-Identity, though I don't recall the >>>>>>>> details, or which draft it was. So what I am about to say might >>>>>>>> bear no >>>>>> relationship to that.) >>>>>>>> I could see how Identity might be used between trust >>>>>> domains, while >>>>>>>> P-Asserted-Identity is used within a trust domain. In that case, >>>>>>>> a verifier might run at the entry point to a trust domain and if >>>>>>>> verification succeeds, insert a P-Asserted-Identity header with >>>>>>>> a corresponding identity. It then might, or might not, remove >>>>>>>> the Identity header. Recipients within the trust domain could >>>>>>>> then use P-Asserted-Identity as the source of identity info. (In >>>>>>>> this scenario, an identity header would only be added to >>>>>>>> requests when they leave the trust domain.) >>>>>>>> >>>>>>>> In this kind of environment, it is only necessary for the >>>>>> verifier to >>>>>>>> omit the P-Asserted-Identity header when verification fails. >>>>>>>> >>>>>>>>> Under what conditions should a verifier remove an Identity >>>>>>>> header field >>>>>>>>> rather than rejecting with 436/437/438? My inclination >>>>>>>> would be to leave it >>>>>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>>>>> concerned, and >>>>>>>>> then make more precise statements concerning mid-dialog requests. >>>>>>>>> Alternatively the update to RFC 4474 could just relax the >>>>>> rules for >>>>>>>>> mid-dialog requests. I think there is some merit in >>>>>>>> relaxing the rules in >>>>>>>>> general, because otherwise there might be situations where >>>>>>>> a legitimate >>>>>>>>> caller cannot establish a call because an Authentication >>>>>>>> Service (outside >>>>>>>>> the UAC's control) is inserting an unverifiable signature >>>>>> (e.g., in >>>>>>>>> Identity-Info placing a URL that the Verifier cannot >>>>>>>> dereference for some >>>>>>>>> reason). >>>>>>>> What you say sounds reasonable to me. >>>>>>>> >>>>>>>> There is however some risk to having a verifier remove >>>>>> identity. The >>>>>>>> problem would be when there are potentially multiple >>>>>> verifiers that >>>>>>>> don't trust one another. If an early one removes the >>>>>> header, then it >>>>>>>> prevents a subsequent verifier from doing its own verification. >>>>>>>> >>>>>>>> This could come up if a request transits a domain on the way to >>>>>>>> another domain. Each domain may wish to do its own verification. >>>>>>>> >>>>>>>> That is an advantage to having the verifier add something to the >>>>>>>> request to indicate the result of its verification. >>>>>>>> >>>>>>>>> One consequence of the Verifier being separated from the >>>>>>>> UAS is that we >>>>>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>>>>> its proxy (for >>>>>>>>> similar reasons that you cited for the Authentication >>>>>>>> Service earlier). So >>>>>>>>> for mid-dialog requests we would need to mandate, or at >>>>>>>> least recommend, >>>>>>>>> that 436/437/438 should not be sent. >>>>>>>> Right. >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 >>>>>>>>>> October 2006 01:44 >>>>>>>>>> To: Elwell, John >>>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Elwell, John wrote: >>>>>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>>>>> >>>>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>>>>> 436, 437 or 438, >>>>>>>>>>> then it MUST NOT invoke the verifier for a subsequent request >>>>>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>>>>> not by some >>>>>>>>>> proxy in front of the UAS. Isn't it valid to have a verifier >>>>>>>>>> in a proxy before the UAS? This rule would forbid that, >>>>>>>>>> because it would cause that proxy to be call stateful. >>>>>>>>>> >>>>>>>>>> I think it would just be better to update the RFC, even though >>>>>>>>>> that is a bit more trouble than not to. >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> on the same >>>>>>>>>>> dialog unless the From header field URI has changed, and in >>>>>>>>>> such cases >>>>>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>>>>> Then a UAC, on >>>>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>>>>> This would allow >>>>>>>>>>> business as usual on this dialog (but without the benefit >>>>>>>>>> of connected >>>>>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>>>>> any change to RFC >>>>>>>>>>> 4474, because verification is optional anyway. >>>>>>>>>>> >>>>>>>>>>> Would this work? >>>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 >>>>>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>>> >>>>>>>>>>>> Cullen, Jon, >>>>>>>>>>>> >>>>>>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>>>>>> you), I would greatly appreciate an opinion from each of you >>>>>>>>>>>> on this remaining issue in connected-identity. Just to >>>>>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to return >>>>>>>>>>>> a 428 response if Identity is missing, but mandates the >>>>>>>>>>>> sending of a 436, 437 or 438 response for certain errors >>>>>>>>>>>> arising while verifying the signature. It seems that for mid >>>>>>>>>>>> dialog requests this behaviour could be harmful. What does >>>>>>>>>>>> the UAC for the mid dialog request do if it receives 436, >>>>>>>>>>>> 437 or 438? If the mid-dialog request was solely for the >>>>>>>>>>>> purpose of connected identity, it can give up and allow the >>>>>>>>>>>> call to continue as is. But if the request was for some >>>>>>>>>>>> other purpose (e.g., renegotiating the session because of >>>>>>>>>>>> hold, say, or session timer refresh), the UAC really wants >>>>>>>>>>>> it to work. For the normal case where the Authentication >>>>>>>>>>>> Service is at a proxy, not at the UAC, the UAC cannot force >>>>>>>>>>>> the Authentication Service to refrain from putting this >>>>>>>>>>>> unverifiable signature in the mid-dialog request, so any >>>>>>>>>>>> attempts to repeat the request would most likely be doomed >>>>>>>>>>>> to getting the same response. >>>>>>>>>>>> >>>>>>>>>>>> It seems there are three things we could do, none very >>>>>>>> attractive: >>>>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>>>>>> 4474 for a verifier by softening the requirements for >>>>>>>>>>>> sending 436, 437 and 438 in response to mid-dialog requests. >>>>>>>>>>>> But then a mid-dialog request from a rogue source would be >>>>>>>>>>>> accepted. >>>>>>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>>>>>> resulted in 436, 437 or 438. But this implies statefulness >>>>>>>>>> at the AS. >>>>>>>>>>>> 3. Accept the fact the mid-dialog requests can fail in this >>>>>>>>>>>> way and therefore things like session refresh and session >>>>>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>>>>> failure. Sounds bad, but it is no different from an initial >>>>>>>>>>>> INVITE request, where there is nothing the UAC can do if the >>>>>>>>>>>> AS inserts an Identity header that gets rejected with 436, >>>>>>>>>> 437 or 438. >>>>>>>>>>>> John >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>> September 2006 19:26 >>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>>>> >>>>>>>>>>>>> John, >>>>>>>>>>>>> >>>>>>>>>>>>> I want to hear what others, especially Jon and Cullen, have >>>>>>>>>>>>> to say about this. >>>>>>>>>>>>> >>>>>>>>>>>>> It is of some concern to me that a call might fail >>>>>>>>>> because of some >>>>>>>>>>>>> problem with the identity mechanism when the same call >>>>>>>> might have >>>>>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>>>>> >>>>>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>>>>> implementation of the verifier. What to do in the case of >>>>>>>>>>>>> the conditions that >>>>>>>>>>>> lead to these >>>>>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>>>>> generate the >>>>>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>>>>> message. And the >>>>>>>>>>>>> policy could conceivably vary based on attributes of the >>>>>>>>>>>>> message, such as whether it is in-dialog or not. >>>>>>>>>>>>> >>>>>>>>>>>>> Does it require a change to 4474 to permit that kind >>>>>> of policy? >>>>>>>>>>>>> It would be annoying if the end user had no control over >>>>>>>>>>>>> the insertion and verification of identity, and it resulted >>>>>>>>>>>>> in calls failing that the user would like to permit. But I >>>>>>>>>>>>> suppose that is itself >>>>>>>> a policy >>>>>>>>>>>>> decision. There are certainly enterprises that want to >>>>>>>>>>>>> exert that kind of control over what users are permitted to >>>>>>>>>>>>> do. >>>>>>>>>>>>> >>>>>>>>>>>>> Paul >>>>>>>>>>>>> >>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>> Paul, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I agree with most of your points, and on reflection I think >>>>>>>>>>>>> I agree that the >>>>>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think RFC 4474 is not a problem as far as sending a 428 >>>>>>>>>>>>> 'Use Identity >>>>>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>>>>> policy, so we could >>>>>>>>>>>>>> say in connected-identity that policy should be to not >>>>>>>> send 428. >>>>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>>>>> because RFC 4474 says >>>>>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>>>>> Interestingly, though, >>>>>>>>>>>>>> there are other failure scenarios that can arise from the >>>>>>>>>>>>> procedures of >>>>>>>>>>>>>> section 6 of RFC 4474 for which no normative statement is >>>>>>>>>>>>> given on how to >>>>>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>>>>> authoritative for the >>>>>>>>>>>>>> domain. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So one way to solve the present problem would be for the >>>>>>>>>>>>> connected-identity >>>>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the case >>>>>>>>>>>>> of mid-dialog >>>>>>>>>>>>>> requests. I guess this would mean that it would update RFC >>>>>>>>>>>>> 4474 as well as >>>>>>>>>>>>>> updating RFC 3261. But I don't like this, because it seems >>>>>>>>>>>>> to remove some of >>>>>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>>>>> responses will be sent, >>>>>>>>>>>>>> and failure to verify a signature will therefore result in >>>>>>>>>>>>> inability to >>>>>>>>>>>>>> process the UPDATE or re-INVITE request, and hence if the >>>>>>>>>>>> UPDATE or >>>>>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>>>>> session timer refresh >>>>>>>>>>>>>> or modifying the session, that action will fail. Then the >>>>>>>>>>>>> call will fail (in >>>>>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>>>>> the session >>>>>>>>>>>>>> modification will fail. I guess this is somewhat analogous >>>>>>>>>>>>> to caller ID >>>>>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>>>>> impossible to establish a >>>>>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>>>>> ability to rectify the >>>>>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>>>>> Authentication Service >>>>>>>>>>>>>> that puts a rogue Identity header field in every request. >>>>>>>>>>>>> In the connected >>>>>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>>>>> already established >>>>>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>>>>> wrong source, then >>>>>>>>>>>>>> sending a 436, 437 or 438 response is indeed the correct >>>>>>>>>>>>> thing to do, and >>>>>>>>>>>>>> overriding the verification procedures of RFC 4474 would >>>>>>>>>>>>> indeed be the wrong >>>>>>>>>>>>>> thing to do. So perhaps we just have to accept that these >>>>>>>>>>>>> response codes can >>>>>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>>>>> sending a 428 and >>>>>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>>>>> verifier might send. >>>>>>>>>>>>>> John >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>>>> September 2006 15:13 >>>>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] When an >>>>>>>>>>>>>>>>> Update is sent. Are there any conditions >>>>>>>> under which >>>>>>>>>>>>>>>>> it might be rejected. Bad identity for example. I think >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>> might need a >>>>>>>>>>>>>>>>> little discussion and also what the UA does when it sends >>>>>>>>>>>>>>> an update >>>>>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>>>>> situation where it is >>>>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>>>>> purposes such as >>>>>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>>>>> because connected >>>>>>>>>>>>>>>> identity fails. >>>>>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>>>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>>> I'm not sure about this. At the least I think this >>>>>> one needs >>>>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the >>>>>>>>>>>>>>> conditions when >>>>>>>>>>>>> it can be >>>>>>>>>>>>>>> violated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>>>>> challenge on an >>>>>>>>>>>>>>> in-dialog request. In some cases it is the right >>>>>> thing to do. >>>>>>>>>>>>>>> A UA that imposes such a requirement will be >>>>>> limited in what >>>>>>>>>>>>>>> it can do, but that may still be right in some cases. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>>>>> Identity header field >>>>>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>>>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>>> This requirement would force the authentication service to >>>>>>>>>>>>> be dialog >>>>>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>>>>> back into the >>>>>>>>>>>>>>> sender of the request. This may require a way for the UAC >>>>>>>>>>>>> to tell the >>>>>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>>>>>>>>>>>>> results in one of >>>>>>>>>>>>>>>> these responses if the mid-dialog request was not solely >>>>>>>>>>>>>>> for the purpose of >>>>>>>>>>>>>>>> connected identity. If solely for the purpose of connected >>>>>>>>>>>>>>> identity there is >>>>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT take >>>>>>>>>>>>> any further >>>>>>>>>>>>>>>> action". >>>>>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think that the remedy to these is in the verifier. The >>>>>>>>>>>>>>> purpose of the verifier is ultimately to drive an >>>>>>>>>>>>>>> authorization >>>>>> decision. If >>>>>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>>>>> identity, then the >>>>>>>>>>>>>>> request should be permitted to continue as if the >>>>>>>>>>>>>>> identity was not present. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unfortunately this would seem to require a revision to >>>>>>>>>>>>>>> 4474 even though the paint is hardly dry on it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If this is done, then there is no need of a mechanism to >>>>>>>>>>>> cause the >>>>>>>>>>>>>>> authentication service *not* to authenticate. If this is >>>>>>>>>>>>> *not* done, >>>>>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>>>>> change to 4474. >>>>>>>>>>>>>>> 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 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 18 09:27:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBPz-0002dB-MT; Wed, 18 Oct 2006 09:25:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBPw-0002bW-Fq for sip@ietf.org; Wed, 18 Oct 2006 09:25:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBHW-0004Wd-Vw for sip@ietf.org; Wed, 18 Oct 2006 09:16:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 06:16:27 -0700 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 k9IDGQBj017677; Wed, 18 Oct 2006 09:16: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 k9IDGLYJ026846; Wed, 18 Oct 2006 09:16:21 -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, 18 Oct 2006 09:16:21 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:16:21 -0400 Message-ID: <45362924.2070804@cisco.com> Date: Wed, 18 Oct 2006 09:16:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Question on REGISTER References: <6FC4416DDE56C44DA0AEE67BC7CA437110FF752E@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110FF752E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 13:16:21.0099 (UTC) FILETIME=[9A75DBB0:01C6F2B7] DKIM-Signature: a=rsa-sha1; q=dns; l=5493; t=1161177386; x=1162041386; 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=20on=20REGISTER |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3DyDooipuEhcCESUaMNqXytABoo9o=3D; b=SUjCguVt65zUXygNgwKZPYK874Gpm/W+1qU2xmkeMsjY4K3Yrhql04Aimcqgns4PEfoVxSML lvJvraCg3eXmwZvRhZam7Es7OZByHwxR/7tMud1LtoDh+1RTx6m1i5Fr; 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: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: sip@ietf.org, CLHaft@aol.com, 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 Brian Stucker wrote: > IMHO-- > > Having implemented registrars and things that register with them. > > The RFC is designed to disallow registrations for the same target > resource at the registrar. This means that ANYONE trying to register > against a particular target resource at the registrar must wait their > turn and no overlapping is allowed (the target resource's contact set is > not allowed to change in parallel). Once the 200 OK to one registration > is sent out though, the next guy in the queue is free to do their thing. Brian - are you saying that if two different UAs, X and Y, are attempting to register to the same AOR, Z, that they must coordinate with one another to prevent concurrent REGISTER requests? How would you expect them to do so? This is a serialization problem for the registrar, not the UAs. > This doesn't mean that the registrar has to send a 491 back to > overlapping registrations from two different sources trying to register > for the same target resource in parallel as long as their SIP > transactions aren't overlapping. overlapping how? Paul > You should only get a 491 if you have a pending registration with the > same SIP transaction context information (tags, callid, etc, matches a > registration that is still being processed). > > BTW- You may want to have a systems engineer take a look at your pacing > algorithm. Depending on the timer intervals involved, you're going to > wind up with some wickedly sinusoidal traffic patterns from most > obvious traffic spreading algorithms. > > Check that. > > Regards, > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, October 17, 2006 9:28 AM >> To: Dean Willis >> Cc: sip@ietf.org; CLHaft@aol.com >> Subject: Re: [Sip] Question on REGISTER >> >> I do agree with Dean on this. >> >> I like the phrase "massive non-workingness". Another Dean-ism >> for the book. >> >> The server you are registering to has no business sending you >> a 491 when you send a second REGISTER to a different AOR. But >> it certainly can send you a 503 if you are trying to send >> 4000 concurrent REGISTERs. >> >> Paul >> >> Dean Willis wrote: >>> CLHaft@aol.com wrote: >>>> I'm working on a gateway between a proprietary system and >> SIP. One >>>> of our new projects involves sending REGISTERs on behalf >> of some of >>>> our users to a third party server. They are pointing at section >>>> 10.2 of RFC 3261 where it states: >>>> >>>> UAs MUST NOT send a new registration (that is, containing new >>>> Contact header field values, as opposed to a >> retransmission) until >>>> they have received a final response from the registrar for the >>>> previous one or the previous REGISTER request has timed out. >>>> >>>> Does this really mean that our gateway must really wait for a >>>> response for one user before we can send a REGISTER for a second >>>> user? This is what we are being told by the third-party >> vendor of >>>> the registration server. I find it hard to believe that >> this is the >>>> intent of the RFC, especially since it allows for >> stateless proxies >>>> to be in the path, where they would not be able to do this. >>> Paul is correct that this section 10.2 text really refers >> to REGISTER >>> requests with the same request-URI and To: value launched >> by a single >>> UA, and its intent is to prevent "stacking up" of pending requests >>> that are effectively going to cancel each other out anyhow. >>> >>> However, you may still want to do some sort of flow control >> or pacing >>> on a sequence of REGISTER requests. Many registrars will >> fall over or >>> at least get blocked up and start dropping requests if they're hit >>> with too many overlapping requests. This is why the "avalanche >>> restart" problem (where perhaps many UAs served by a single >> registrar >>> reset at the same time due to a power failure) is such a >> big problem for large systems. >>> Serializing the requests is probably the absolute safest >> flow control >>> model. Note that this places no real dependencies on >> proxies, just on >>> multiuser UAs. By serialization, I mean that the UA does >> not start a >>> new register request until it has received a 200 OK (or other final >>> response) to the preceding request. >>> >>> More sophisticated systems might launch REGISTER requests at some >>> rate-per-second, with reasonable numbers for real hardware probably >>> ranging from 4 to 400. Certainly if you drop 4,000 registration >>> requests on a server within a 1-second window you are going to see >>> some massive not-workingness. >>> >>> >>> -- >>> 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 Wed Oct 18 09:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBV4-00088C-Gp; Wed, 18 Oct 2006 09:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBV2-000886-Rc for sip@ietf.org; Wed, 18 Oct 2006 09:30:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBV1-0007aV-HJ for sip@ietf.org; Wed, 18 Oct 2006 09:30:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 06:30:23 -0700 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 k9IDUNOa024293; Wed, 18 Oct 2006 09:30: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 k9IDUMDM010061; Wed, 18 Oct 2006 09:30:22 -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, 18 Oct 2006 09:30:22 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:30:22 -0400 Message-ID: <45362C6D.2000406@cisco.com> Date: Wed, 18 Oct 2006 09:30:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments References: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 13:30:22.0249 (UTC) FILETIME=[8FD32990:01C6F2B9] DKIM-Signature: a=rsa-sha1; q=dns; l=2681; t=1161178223; x=1162042223; 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]draft-rosenberg-sip-identity-coexistence-00.txt=20further=0 A=20comments |To:=22Jesske,=20R=22=20; X=v=3Dcisco.com=3B=20h=3D4594ZzISDxmDRiukQilYwyarxwY=3D; b=Acda9PQc8Y/GG65c8c+fUBS8WR5/cqLObuNmd7RYbHDtff5owcfQDglJcGf3a9nys7WzoWOo YOMWYRSD+P8Ct8xnZen7LdIOyttpndgdqav/VOy1sCWF3tGeufNDKkQv; 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: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Roland's comments below are a reflection of a general issue about the semantics of identity that seems to be brewing. On one hand we have a set of people who are trying to restore the lost usefulness of the From header, by providing a way to prove its validity as an identity. On the other hand we have a different set of people who *like* the fact that From is an unauthenticated assertion of identity, and want to keep it that way. Or do I have the latter wrong? Maybe its ok if From gets authenticated as long as there is still a way to have another asserted identity as well. Paul Jesske, R wrote: > Dear all, > With regard to the following section I have some concerns regarding the > thought use of the P-Asserted-Identity. > > 4.3. Ingress Proxy > > .... If the identity > is verified, the ingress proxy SHOULD insert a P-Asserted-ID header > field containing the identity contained in the From header field of > the request. The proxy SHOULD NOT remove the Identity and Identity- > Info header fields. This allows for SIP networks where there are > more than two administrative domains in a request path, and also > allows for a UA to verify the signature on its own if it should > desire.... > > This will violate the use of the From and P-Asserted-Identity header > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping > with the PSTN. > > The P-Asserted-Identity is used as a public ID that is trusted. The From > header is set by the user itself and is untrusted. So that there is the > possibility to have two different identities within one INVITE. > To equalise such identities within a B2BUA at the ingress even if the >>From is also a now secure and trusted ID. > > Within the NGN this two identities are used for PBX services to present > the main PBX number and a individual extension of the PBX. > > Also the deletion and re-inclusion is against the rules of the RFC3325. > The destination domain is not allowed to change the identity of the > originating domain. > > If such procedures will be done also charging and billing mechanisms > used between domains will be violated. because the P-Asserted-Identity > is the base identity of the origin domain on Billing and charging. > > Best Regards > > Roland > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 18 09:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBeI-0006Ck-0P; Wed, 18 Oct 2006 09:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBeG-0006Cf-NV for sip@ietf.org; Wed, 18 Oct 2006 09:39:56 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBeA-0000lz-8c for sip@ietf.org; Wed, 18 Oct 2006 09:39:56 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 836FE6C01C; Wed, 18 Oct 2006 09:39:40 -0400 (EDT) Subject: Re: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Jonathan Rosenberg In-Reply-To: <4533FBAA.40506@cisco.com> References: <4522AFC5.10306@lucent.com> <4533FBAA.40506@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 18 Oct 2006 09:39:44 -0400 Message-Id: <1161178784.2751.32.camel@132-177-120-205.ip.sipit.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 On Mon, 2006-10-16 at 17:37 -0400, Jonathan Rosenberg wrote: > Thanks for startign on this problem, Vijay. > > I understand how the mechanism can diagnose the problem, but I don't see > how it can fix it. In particular, when the UAC gets a 140 or 141, and > then the transaction times out, the document says it should retry with > congestion controlled transport. Well, that would work on the first hop. > But nothing in the request would tell the proxy NOT to switch back to > UDP. Unless you use sips, and thats assuming its implemented AND > assuming its over TLS and all of that... The retried request could be sent with a request URI that includes a url parameter of 'transport=tcp'. That aught to cause intermediate hops to try that first at least. There are going to be cases, such as a proxy in the path that can only do UDP, where it just won't be possible to make it work reliably. I think that the most we can really achieve is a good diagnostic. > Another problem with the mechanism you have proposed is the long delays > involved in waiting for the transaction to timeout. > > You have discarded the 4xx case, and I think it has merit. You are > correct that it may result in false positives - but so what? I think that forcing a call to fail that might have succeeded is pretty serious. > There are > no increases in call setup delays (to me, a worse result). And its > reliable. It might help solve this problem above if the 4xx response > contains a URI that reaches the resource that wanted to send the error > response, but has a DNS entry only for TCP (like a TCP-only GRUU for a > UAS). The client also retries with TCP. In the trapezoid model this > would at least get you TCP all the way to the terminating proxy. In > configurations with many more than that, you do still have the same > problem of no way of explicitly requesting TCP. We can solve that with a > Proxy-Require I suppose, though we're talking about a proxy upgrade at > each hop. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Oct 18 09:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBj9-0001gP-Mx; Wed, 18 Oct 2006 09:44:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBj8-0001gK-JG for sip@ietf.org; Wed, 18 Oct 2006 09:44:58 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBj4-0001Uw-BO for sip@ietf.org; Wed, 18 Oct 2006 09:44:58 -0400 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 48DFB6C01C; Wed, 18 Oct 2006 09:44:49 -0400 (EDT) Subject: RE: [Sip] I-D on handling large UDP responses From: Scott Lawrence To: Samir Srivastava In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F08C016@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60F08C016@zrc2hxm2.corp.nortel.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Wed, 18 Oct 2006 09:44:53 -0400 Message-Id: <1161179093.2751.38.camel@132-177-120-205.ip.sipit.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Mon, 2006-10-16 at 03:25 -0500, Samir Srivastava wrote: > The proposed mechanism can be used only for REQ/RSP. How can we address > the problems caused in 200 OK (Offer) and ACK (Answer) due to UDP > between some proxies ? In the current model, UAC gets the complete > Large 200 OK (with delayed arrival of 140/141 or you change the current > solution w.r.t. 140/141), but ACK follows the different IP hops etc... Are you asking how this helps to detect a lost ACK? If so, I don't think that it does, but a lost ACK will cause the final response to be resent, so you'll know anyway. Eventually the 14x should arrive, providing a hint as to the possible problem. Besides, the only time the ACK is likely to be lost due to UDP fragmentation is if it has the SDP answer and is itself large, which the sender already knows. > We might be doing congestion handling in SIP for UDP transports in > future, where some of it is provided by other transports. In my purist > mind, SIP messages are becoming huge, so UDP is no more relevant. UDP > was taken initially, as it was simple to transport short SIP message at > that time. I'm hoping that providing better diagnostics that show how UDP fails will cause end users to put pressure on vendors to support TCP and/or TLS. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Architect - Pingtel Corp. http://www.pingtel.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 Oct 18 10:06:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC1r-0007U3-Pf; Wed, 18 Oct 2006 10:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC1p-0007Tx-Nf for sip@ietf.org; Wed, 18 Oct 2006 10:04:17 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaC1l-0004dh-KJ for sip@ietf.org; Wed, 18 Oct 2006 10:04:17 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9IE49JS007266; Wed, 18 Oct 2006 09:04:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Oct 2006 09:04:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Oct 2006 16:04:07 +0200 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] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 comments) Date: Wed, 18 Oct 2006 16:04:05 +0200 Message-ID: <5D1A7985295922448D5550C94DE291806258C9@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 comments) Thread-Index: Acbytwa74TrJrSbqSgWExn7VkS8XMgABuXAQ From: "Drage, Keith \(Keith\)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 18 Oct 2006 14:04:07.0047 (UTC) FILETIME=[46B2D170:01C6F2BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 Cc: Cullen Jennings , SIP , "Elwell, John" , Dan Wing , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 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 would suggest the problem is not the making of the new assertion. The issue is the removal of the assertion that some other entity made, that may be equally valid. Note that this may particularly be an issue in emergency calls, where PSAPs object to the removal of any information about the user (correct or incorrect), and in some countries, they may want to believe the asserter in the trust domain before they believe the user and his certificate server owner. Regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 18 October 2006 14:09 > To: shida@ntt-at.com > Cc: Cullen Jennings; SIP; Elwell,John; Jon Peterson; Dan Wing > Subject: Re: [Sip] RE: Rejecting connected identity (was RE:=20 > draft-ietf-sip-connecte d-id entity-01 comments) >=20 >=20 >=20 > Shida Schubert wrote: > > Although using P-A-ID may look like a good approach for=20 > this, I don't=20 > > know if it's really a good idea as it seems to change the=20 > semantics of=20 > > P-A-ID. >=20 > I don't think this *is* changing the semantics of P-A-ID. >=20 > The semantics are very simple: something in the trust domain=20 > determines the identity of the message and inserts to header=20 > for the benefit of others in the trust domain. The entity=20 > doing the assertion has full latitude about how it determines=20 > the identity it asserts. >=20 > What this is doing is providing a new way to make that determination. > The new way may not be appropriate in all environments, and=20 > that's fine. >=20 > > Also, it may generates some issues when P-A-ID already=20 > exists in the=20 > > message along with connected-identity. >=20 > That part needs to be clarified. >=20 > > Following illustrates potential problems. > >=20 > > connected-id(FROM): carol@b.com > > P-A-ID: carol@b.com > >=20 > > Now, following the proposal by John when Case 2 is deployed, and=20 > > assuming the verification of identity failed, it will still forward=20 > > the message as it is if we allow Case 2. >=20 > I guess here you are assuming: > - the P-A-ID was present before the verifier got the message > - the verifier leaves it in the message when verification fails >=20 > These are assumptions about the interaction of preexisting=20 > P-A-ID and connected identity verification. There is an issue=20 > there, but there are other possible answers to it. >=20 > > When UAS receives the request > > it will see both the identity-info/header and P-A-ID with the value=20 > > equivalent to the value in the FROM header.. If UAS has no=20 > ability to=20 > > verify the signature itself, it will assume that the verification=20 > > worked. P-A-ID looks like a good place to indicate the=20 > success of the=20 > > verification but it might need something else. >=20 > IMO the presence of the P-A-ID is not evidence that the=20 > verification worked. It is merely in indication that someone=20 > in the trust domain asserted this identity. It could be=20 > because the verification of the Identity worked, or because=20 > some other kind of authentication worked, or it could be=20 > because some bogus party within the trust domain lied. >=20 > If you choose to trust the P-A-ID, it means you choose to=20 > believe in the trust model. Nothing more. >=20 > > As for Cullen's comments. I agree with Paul here, if the security=20 > > policy at the verification side would allow request without=20 > identity,=20 > > it should forward the request even if the verification fails. > >=20 > > Lastly, if P-A-ID value is used in some context, changing the value=20 > > may cause some problem as well(Assuming P-A-ID was there but a=20 > > different value from FROM value > verifier after=20 > verification succeeds=20 > > change the P-A-ID value to that of FROM). > >=20 > > Regards > > Shida > >=20 > > Paul Kyzivat wrote: > >> > >> Cullen Jennings wrote: > >>> I'm generally on board with things like you are=20 > suggesting below and=20 > >>> what is suggested in draft-rosenberg-sip-identity-coexistence. > >>> However, I want to think very carefully about the security=20 > >>> properties of not rejecting things that failed based on security=20 > >>> properties - I'm not sure what I think of this yet. > >>> > >>> Any time you allow a security action that failed to=20 > continue sending=20 > >>> the request downstream, you run the risk that something=20 > further down=20 > >>> stream assumes that the security action worked because it=20 > must have=20 > >>> happened upstream. Clearly from a security point of view=20 > it would be=20 > >>> better not to have upstream elements do the security=20 > validation for=20 > >>> a downstream element but we did decide long ago that when doing=20 > >>> Identity we were going to allow for this so that we could migrate=20 > >>> from UAs that do not support Identity to system that does. > >>> > >>> So let me flip this around the other way and ask - do we=20 > really need=20 > >>> to allow for a request that failed verification to not=20 > result in an=20 > >>> error? > >> I think the poster child for this is when the error is 437=20 > >> Unsupported Certificate. > >> > >> In this case the caller may be trapped. It has an identity=20 > service it=20 > >> can't control, that unconditionally adds an identity. And then the=20 > >> callee has an authentication verifier in front of it. As things=20 > >> stand, that verifier is required to reject requests with certs it=20 > >> doesn't understand, even in cases where it will permit=20 > requests with=20 > >> no identity at all. > >> > >> Paul > >> > >>> Are there use cases where the verification would fail and=20 > we really=20 > >>> do want to continue with the message? If these cases would only=20 > >>> happen in a fairly broken system, then it might not be worth the=20 > >>> security problems they would cause. I don't know what I=20 > think but I=20 > >>> am interested in where we might need this and if there might be=20 > >>> other ways to skin the cat in those situations. > >>> > >>> Cullen > >>> > >>> > >>> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: > >>> > >>>> John, > >>>> > >>>> What you outline below is exactly what I had in mind. > >>>> > >>>> Paul > >>>> > >>>> Elwell, John wrote: > >>>>> Paul, > >>>>> Dan Wing made a suggestion that P-Asserted-Identity=20 > would fulfil=20 > >>>>> your requirement. I guess it would work like this. > >>>>> A Verifier not located at the UAS would attempt to verify the=20 > >>>>> signature in the Identity header field. > >>>>> - Case A - verification succeeds. The Verifier inserts into the=20 > >>>>> forwarded request a P-Asserted-Identity header field containing=20 > >>>>> the verified URI (from the From header field) in the forwarded=20 > >>>>> request. The Identity and Identity-Info header fields=20 > will still=20 > >>>>> be present and available should another verifier be encountered=20 > >>>>> downstream. > >>>>> - Case B - verification fails but request not rejected. The=20 > >>>>> verifier is unable to verify (e.g., because it can't=20 > dereference=20 > >>>>> the URL) but according to policy does not reject the=20 > request. It=20 > >>>>> simply forwards the request as is. > >>>>> If there is a further verifier downstream, that too can=20 > attempt to=20 > >>>>> verify the signature. > >>>>> - Case C - verification fails but request is rejected. The=20 > >>>>> verifier is unable to verify (e.g., bad signature) and=20 > according=20 > >>>>> to policy it rejects the request. > >>>>> A UAS that does not contain a verifier can simply use=20 > >>>>> P-Asserted-Identity, if present. > >>>>> This seems to have some synergy with=20 > >>>>> draft-rosenberg-sip-identity-coexistence. In fact the=20 > relaxation=20 > >>>>> of rules concerning rejection by a verifier that is unable to=20 > >>>>> verify a signature might be beneficial to that proposal. > >>>>> I will omit discussion of the mechanics of=20 > documentation until I=20 > >>>>> see what reaction there is to the technical proposal. > >>>>> John > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October > >>>>>> 2006 13:54 > >>>>>> To: Elwell, John > >>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Elwell, John wrote: > >>>>>>> Paul, > >>>>>>> > >>>>>>> Your message arrived just after I had submitted 02, so your > >>>>>> comments are not > >>>>>>> taken into account in that version. However, I felt it was > >>>>>> useful to get 02 > >>>>>>> out as a baseline for further discussion. > >>>>>> Sure. I too am interested in seeing other inputs on=20 > this subject. > >>>>>> > >>>>>>> It seems the remaining issue is whether to add an explicit > >>>>>> indication of > >>>>>>> removal of the Identity header field by a verifier that has > >>>>>> been unable to > >>>>>>> verify the signature. Whilst this may make sense, I am > >>>>>> concerned it starts > >>>>>>> to go beyond the scope of connected-identity, so I would like=20 > >>>>>>> other opinions, especially from the chairs and from=20 > the authors > >>>>>> of Identity. > >>>>>> > >>>>>> Rather than adding something to indicate that identity has been > >>>>>> *removed* due to failure to verify, I am advocating adding=20 > >>>>>> something to indicate that verification has *succeeded*, while=20 > >>>>>> leaving the identity header in place. In this way, a=20 > downstream=20 > >>>>>> element may *either* trust the info added by the=20 > verifier or do=20 > >>>>>> its own verification of the identity header. > >>>>>> > >>>>>> Of course this is only significant if the verifier is=20 > doing work=20 > >>>>>> for downstream elements, and not for itself. > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>>> John > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent:=20 > 05 October > >>>>>>>> 2006 16:29 > >>>>>>>> To: Elwell, John > >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: > >>>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Elwell, John wrote: > >>>>>>>>> Paul, > >>>>>>>>> > >>>>>>>>> So your proposal is that the connected-identity RFC should > >>>>>>>> update RFC 4474 > >>>>>>>>> to somehow relax rules at a verifier. Correct? > >>>>>>>> Yeah, I think so. > >>>>>>>> > >>>>>>>>> So the next question concerns the way in which these > >>>>>> rules should be > >>>>>>>>> relaxed. One problem with the verifier not being located at > >>>>>>>> the UAS but at > >>>>>>>>> some proxy is that the UAS might be configured always to > >>>>>>>> trust identities > >>>>>>>>> received in requests via the verifier's proxy if an > >>>>>>>> Identity header field is > >>>>>>>>> present, on the assumption that the signature has been > >>>>>>>> checked by the > >>>>>>>>> verifier. Therefore it sounds like the verifier, if it does > >>>>>>>> not reject a > >>>>>>>>> request with a bad signature, should remove the Identity > >>>>>>>> header field (and > >>>>>>>>> also Identity-Info) before forwarding the request towards > >>>>>>>> the target. > >>>>>>>> > >>>>>>>> (I think I have seen someone propose combining the use of=20 > >>>>>>>> Identity and P-Asserted-Identity, though I don't recall the=20 > >>>>>>>> details, or which draft it was. So what I am about=20 > to say might=20 > >>>>>>>> bear no > >>>>>> relationship to that.) > >>>>>>>> I could see how Identity might be used between trust > >>>>>> domains, while > >>>>>>>> P-Asserted-Identity is used within a trust domain. In that=20 > >>>>>>>> case, a verifier might run at the entry point to a=20 > trust domain=20 > >>>>>>>> and if verification succeeds, insert a P-Asserted-Identity=20 > >>>>>>>> header with a corresponding identity. It then might,=20 > or might=20 > >>>>>>>> not, remove the Identity header. Recipients within the trust=20 > >>>>>>>> domain could then use P-Asserted-Identity as the source of=20 > >>>>>>>> identity info. (In this scenario, an identity header=20 > would only=20 > >>>>>>>> be added to requests when they leave the trust domain.) > >>>>>>>> > >>>>>>>> In this kind of environment, it is only necessary for the > >>>>>> verifier to > >>>>>>>> omit the P-Asserted-Identity header when verification fails. > >>>>>>>> > >>>>>>>>> Under what conditions should a verifier remove an Identity > >>>>>>>> header field > >>>>>>>>> rather than rejecting with 436/437/438? My inclination > >>>>>>>> would be to leave it > >>>>>>>>> as a matter of policy as far as the update to RFC 4474 is > >>>>>>>> concerned, and > >>>>>>>>> then make more precise statements concerning=20 > mid-dialog requests. > >>>>>>>>> Alternatively the update to RFC 4474 could just relax the > >>>>>> rules for > >>>>>>>>> mid-dialog requests. I think there is some merit in > >>>>>>>> relaxing the rules in > >>>>>>>>> general, because otherwise there might be situations where > >>>>>>>> a legitimate > >>>>>>>>> caller cannot establish a call because an Authentication > >>>>>>>> Service (outside > >>>>>>>>> the UAC's control) is inserting an unverifiable signature > >>>>>> (e.g., in > >>>>>>>>> Identity-Info placing a URL that the Verifier cannot > >>>>>>>> dereference for some > >>>>>>>>> reason). > >>>>>>>> What you say sounds reasonable to me. > >>>>>>>> > >>>>>>>> There is however some risk to having a verifier remove > >>>>>> identity. The > >>>>>>>> problem would be when there are potentially multiple > >>>>>> verifiers that > >>>>>>>> don't trust one another. If an early one removes the > >>>>>> header, then it > >>>>>>>> prevents a subsequent verifier from doing its own=20 > verification. > >>>>>>>> > >>>>>>>> This could come up if a request transits a domain on=20 > the way to=20 > >>>>>>>> another domain. Each domain may wish to do its own=20 > verification. > >>>>>>>> > >>>>>>>> That is an advantage to having the verifier add something to=20 > >>>>>>>> the request to indicate the result of its verification. > >>>>>>>> > >>>>>>>>> One consequence of the Verifier being separated from the > >>>>>>>> UAS is that we > >>>>>>>>> don't want to rely on stateful behaviour at the Verifier or > >>>>>>>> its proxy (for > >>>>>>>>> similar reasons that you cited for the Authentication > >>>>>>>> Service earlier). So > >>>>>>>>> for mid-dialog requests we would need to mandate, or at > >>>>>>>> least recommend, > >>>>>>>>> that 436/437/438 should not be sent. > >>>>>>>> Right. > >>>>>>>> > >>>>>>>> Paul > >>>>>>>> > >>>>>>>>> John > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03=20 > >>>>>>>>>> October 2006 01:44 > >>>>>>>>>> To: Elwell, John > >>>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP > >>>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected=20 > identity (was RE: > >>>>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>> Thinking further on this, perhaps there is a 4th way: > >>>>>>>>>>> > >>>>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with > >>>>>>>>>> 436, 437 or 438, > >>>>>>>>>>> then it MUST NOT invoke the verifier for a subsequent=20 > >>>>>>>>>>> request > >>>>>>>>>> This assumes that the verifier is invoked by the UAS, and > >>>>>>>> not by some > >>>>>>>>>> proxy in front of the UAS. Isn't it valid to have=20 > a verifier=20 > >>>>>>>>>> in a proxy before the UAS? This rule would forbid that,=20 > >>>>>>>>>> because it would cause that proxy to be call stateful. > >>>>>>>>>> > >>>>>>>>>> I think it would just be better to update the RFC, even=20 > >>>>>>>>>> though that is a bit more trouble than not to. > >>>>>>>>>> > >>>>>>>>>> Paul > >>>>>>>>>> > >>>>>>>>>>> on the same > >>>>>>>>>>> dialog unless the From header field URI has=20 > changed, and in > >>>>>>>>>> such cases > >>>>>>>>>>> SHOULD NOT make use of the unverified connected-identity. > >>>>>>>>>> Then a UAC, on > >>>>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. > >>>>>>>>>> This would allow > >>>>>>>>>>> business as usual on this dialog (but without the benefit > >>>>>>>>>> of connected > >>>>>>>>>>> identity, therefore no worse than at present). It avoids > >>>>>>>>>> any change to RFC > >>>>>>>>>>> 4474, because verification is optional anyway. > >>>>>>>>>>> > >>>>>>>>>>> Would this work? > >>>>>>>>>>> > >>>>>>>>>>> John > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 > >>>>>>>>>>>> To: Cullen Jennings; Jon Peterson > >>>>>>>>>>>> Cc: SIP; Paul Kyzivat > >>>>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: > >>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>>>> > >>>>>>>>>>>> Cullen, Jon, > >>>>>>>>>>>> > >>>>>>>>>>>> In case you missed this (it wasn't addressed directly to=20 > >>>>>>>>>>>> you), I would greatly appreciate an opinion from each of=20 > >>>>>>>>>>>> you on this remaining issue in=20 > connected-identity. Just to=20 > >>>>>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to=20 > >>>>>>>>>>>> return a 428 response if Identity is missing,=20 > but mandates=20 > >>>>>>>>>>>> the sending of a 436, 437 or 438 response for certain=20 > >>>>>>>>>>>> errors arising while verifying the signature. It=20 > seems that=20 > >>>>>>>>>>>> for mid dialog requests this behaviour could be harmful.=20 > >>>>>>>>>>>> What does the UAC for the mid dialog request do if it=20 > >>>>>>>>>>>> receives 436, > >>>>>>>>>>>> 437 or 438? If the mid-dialog request was solely for the=20 > >>>>>>>>>>>> purpose of connected identity, it can give up=20 > and allow the=20 > >>>>>>>>>>>> call to continue as is. But if the request was for some=20 > >>>>>>>>>>>> other purpose (e.g., renegotiating the session=20 > because of=20 > >>>>>>>>>>>> hold, say, or session timer refresh), the UAC=20 > really wants=20 > >>>>>>>>>>>> it to work. For the normal case where the Authentication=20 > >>>>>>>>>>>> Service is at a proxy, not at the UAC, the UAC=20 > cannot force=20 > >>>>>>>>>>>> the Authentication Service to refrain from putting this=20 > >>>>>>>>>>>> unverifiable signature in the mid-dialog request, so any=20 > >>>>>>>>>>>> attempts to repeat the request would most likely=20 > be doomed=20 > >>>>>>>>>>>> to getting the same response. > >>>>>>>>>>>> > >>>>>>>>>>>> It seems there are three things we could do, none very > >>>>>>>> attractive: > >>>>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC > >>>>>>>>>>>> 4474 for a verifier by softening the requirements for=20 > >>>>>>>>>>>> sending 436, 437 and 438 in response to=20 > mid-dialog requests. > >>>>>>>>>>>> But then a mid-dialog request from a rogue=20 > source would be=20 > >>>>>>>>>>>> accepted. > >>>>>>>>>>>> 2. Say that the Authentication Service should omit the=20 > >>>>>>>>>>>> signing of mid-dialog requests if a previous attempt has=20 > >>>>>>>>>>>> resulted in 436, 437 or 438. But this implies=20 > statefulness > >>>>>>>>>> at the AS. > >>>>>>>>>>>> 3. Accept the fact the mid-dialog requests can=20 > fail in this=20 > >>>>>>>>>>>> way and therefore things like session refresh=20 > and session=20 > >>>>>>>>>>>> renegotiation cannot be done, probably resulting in call=20 > >>>>>>>>>>>> failure. Sounds bad, but it is no different from=20 > an initial=20 > >>>>>>>>>>>> INVITE request, where there is nothing the UAC can do if=20 > >>>>>>>>>>>> the AS inserts an Identity header that gets=20 > rejected with=20 > >>>>>>>>>>>> 436, > >>>>>>>>>> 437 or 438. > >>>>>>>>>>>> John > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22=20 > >>>>>>>>>>>>> September 2006 19:26 > >>>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: > >>>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) > >>>>>>>>>>>>> > >>>>>>>>>>>>> John, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I want to hear what others, especially Jon and Cullen,=20 > >>>>>>>>>>>>> have to say about this. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It is of some concern to me that a call might fail > >>>>>>>>>> because of some > >>>>>>>>>>>>> problem with the identity mechanism when the same call > >>>>>>>> might have > >>>>>>>>>>>>> succeeded in the absence of any identity. > >>>>>>>>>>>>> > >>>>>>>>>>>>> But possibly the solution to this is policy in the=20 > >>>>>>>>>>>>> implementation of the verifier. What to do in=20 > the case of=20 > >>>>>>>>>>>>> the conditions that > >>>>>>>>>>>> lead to these > >>>>>>>>>>>>> errors could be configurable in the verifier: either to > >>>>>>>>>>>> generate the > >>>>>>>>>>>>> error or simply to remove the identity info from the > >>>>>>>>>>>> message. And the > >>>>>>>>>>>>> policy could conceivably vary based on=20 > attributes of the=20 > >>>>>>>>>>>>> message, such as whether it is in-dialog or not. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Does it require a change to 4474 to permit that kind > >>>>>> of policy? > >>>>>>>>>>>>> It would be annoying if the end user had no=20 > control over=20 > >>>>>>>>>>>>> the insertion and verification of identity, and it=20 > >>>>>>>>>>>>> resulted in calls failing that the user would like to=20 > >>>>>>>>>>>>> permit. But I suppose that is itself > >>>>>>>> a policy > >>>>>>>>>>>>> decision. There are certainly enterprises that want to=20 > >>>>>>>>>>>>> exert that kind of control over what users are=20 > permitted=20 > >>>>>>>>>>>>> to do. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Paul > >>>>>>>>>>>>> > >>>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>>> Paul, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I agree with most of your points, and on reflection I=20 > >>>>>>>>>>>>>> think > >>>>>>>>>>>>> I agree that the > >>>>>>>>>>>>>> solution has to be with the verifier. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I think RFC 4474 is not a problem as far as=20 > sending a 428 > >>>>>>>>>>>>> 'Use Identity > >>>>>>>>>>>>>> Header' response is concerned, because that is left to > >>>>>>>>>>>>> policy, so we could > >>>>>>>>>>>>>> say in connected-identity that policy should be to not > >>>>>>>> send 428. > >>>>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, > >>>>>>>>>>>>> because RFC 4474 says > >>>>>>>>>>>>>> that they MUST be sent under respective conditions. > >>>>>>>>>>>>> Interestingly, though, > >>>>>>>>>>>>>> there are other failure scenarios that can=20 > arise from the > >>>>>>>>>>>>> procedures of > >>>>>>>>>>>>>> section 6 of RFC 4474 for which no normative=20 > statement is > >>>>>>>>>>>>> given on how to > >>>>>>>>>>>>>> respond, e.g. invalid Date header field, signer not > >>>>>>>>>>>>> authoritative for the > >>>>>>>>>>>>>> domain. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So one way to solve the present problem would=20 > be for the > >>>>>>>>>>>>> connected-identity > >>>>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the=20 > >>>>>>>>>>>>>> case > >>>>>>>>>>>>> of mid-dialog > >>>>>>>>>>>>>> requests. I guess this would mean that it would update=20 > >>>>>>>>>>>>>> RFC > >>>>>>>>>>>>> 4474 as well as > >>>>>>>>>>>>>> updating RFC 3261. But I don't like this, because it=20 > >>>>>>>>>>>>>> seems > >>>>>>>>>>>>> to remove some of > >>>>>>>>>>>>>> the security properties of RFC 4474. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 > >>>>>>>>>>>>> responses will be sent, > >>>>>>>>>>>>>> and failure to verify a signature will=20 > therefore result=20 > >>>>>>>>>>>>>> in > >>>>>>>>>>>>> inability to > >>>>>>>>>>>>>> process the UPDATE or re-INVITE request, and=20 > hence if the > >>>>>>>>>>>> UPDATE or > >>>>>>>>>>>>>> re-INVITE request was for some other purpose such as > >>>>>>>>>>>>> session timer refresh > >>>>>>>>>>>>>> or modifying the session, that action will=20 > fail. Then the > >>>>>>>>>>>>> call will fail (in > >>>>>>>>>>>>>> the case of inability to refresh the session timer) or > >>>>>>>>>> the session > >>>>>>>>>>>>>> modification will fail. I guess this is somewhat=20 > >>>>>>>>>>>>>> analogous > >>>>>>>>>>>>> to caller ID > >>>>>>>>>>>>>> verification failure in an INVITE request - it is > >>>>>>>>>>>>> impossible to establish a > >>>>>>>>>>>>>> call if verification fails. Moreover, the UAC has no > >>>>>>>>>>>>> ability to rectify the > >>>>>>>>>>>>>> situation, since it is at the mercy of a proxy-based > >>>>>>>>>>>>> Authentication Service > >>>>>>>>>>>>>> that puts a rogue Identity header field in=20 > every request. > >>>>>>>>>>>>> In the connected > >>>>>>>>>>>>>> identity case, the only difference is that the call is > >>>>>>>>>>>>> already established > >>>>>>>>>>>>>> but is likely to fail if verification fails. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the > >>>>>>>>>>>>> wrong source, then > >>>>>>>>>>>>>> sending a 436, 437 or 438 response is indeed=20 > the correct > >>>>>>>>>>>>> thing to do, and > >>>>>>>>>>>>>> overriding the verification procedures of RFC=20 > 4474 would > >>>>>>>>>>>>> indeed be the wrong > >>>>>>>>>>>>>> thing to do. So perhaps we just have to accept=20 > that these > >>>>>>>>>>>>> response codes can > >>>>>>>>>>>>>> be received and will lead to failure. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So, my preferred way forward is simply to recommend not > >>>>>>>>>>>>> sending a 428 and > >>>>>>>>>>>>>> accept the consequences of other responses that the > >>>>>>>>>>>>> verifier might send. > >>>>>>>>>>>>>> John > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>>> From: Paul Kyzivat=20 > [mailto:pkyzivat@cisco.com] Sent: 22=20 > >>>>>>>>>>>>>>> September 2006 15:13 > >>>>>>>>>>>>>>> To: Elwell, John > >>>>>>>>>>>>>>> Cc: Cullen Jennings; SIP > >>>>>>>>>>>>>>> Subject: Re: [Sip] RE: > >>>>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments > >>>>>>>>>>>>>>> Elwell, John wrote: > >>>>>>>>>>>>>>>>> From: Cullen Jennings=20 > [mailto:fluffy@cisco.com] When=20 > >>>>>>>>>>>>>>>>> an Update is sent. Are there any conditions > >>>>>>>> under which > >>>>>>>>>>>>>>>>> it might be rejected. Bad identity for example. I=20 > >>>>>>>>>>>>>>>>> think that > >>>>>>>>>>>>> might need a > >>>>>>>>>>>>>>>>> little discussion and also what the UA does when it=20 > >>>>>>>>>>>>>>>>> sends > >>>>>>>>>>>>>>> an update > >>>>>>>>>>>>>>>>> with a no identity and it gets rejected. > >>>>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a > >>>>>>>>>>>>>>> situation where it is > >>>>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for > >>>>>>>>>>>>>>> purposes such as > >>>>>>>>>>>>>>>> session timer refresh or session re-negotiation) just > >>>>>>>>>>>>>>> because connected > >>>>>>>>>>>>>>>> identity fails. > >>>>>>>>>>>>>>>> My proposed fix is as follows: > >>>>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog=20 > >>>>>>>>>>>>>>>> request > >>>>>>>>>>>>>>> with 428 'Use > >>>>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>>>> I'm not sure about this. At the least I think this > >>>>>> one needs > >>>>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the=20 > >>>>>>>>>>>>>>> conditions when > >>>>>>>>>>>>> it can be > >>>>>>>>>>>>>>> violated. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I see this as somewhat analogous to doing a digest > >>>>>>>>>>>> challenge on an > >>>>>>>>>>>>>>> in-dialog request. In some cases it is the right > >>>>>> thing to do. > >>>>>>>>>>>>>>> A UA that imposes such a requirement will be > >>>>>> limited in what > >>>>>>>>>>>>>>> it can do, but that may still be right in some cases. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an > >>>>>>>>>>>>>>> Identity header field > >>>>>>>>>>>>>>>> to a mid-dialog request if a previous request on that > >>>>>>>>>>>>>>> dialog has resulted in > >>>>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported=20 > Certificate'=20 > >>>>>>>>>>>>>>>> or > >>>>>>>>>>>>>>> 438 'Invalid > >>>>>>>>>>>>>>>> Identity Header'. > >>>>>>>>>>>>>>> This requirement would force the=20 > authentication service=20 > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>> be dialog > >>>>>>>>>>>>>>> stateful, which is not ideal. Better to push the state > >>>>>>>>>>>>> back into the > >>>>>>>>>>>>>>> sender of the request. This may require a way for the=20 > >>>>>>>>>>>>>>> UAC > >>>>>>>>>>>>> to tell the > >>>>>>>>>>>>>>> authentication service not to act. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog=20 > request that > >>>>>>>>>>>>>>> results in one of > >>>>>>>>>>>>>>>> these responses if the mid-dialog request was not=20 > >>>>>>>>>>>>>>>> solely > >>>>>>>>>>>>>>> for the purpose of > >>>>>>>>>>>>>>>> connected identity. If solely for the purpose of=20 > >>>>>>>>>>>>>>>> connected > >>>>>>>>>>>>>>> identity there is > >>>>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT=20 > >>>>>>>>>>>>>>>> take > >>>>>>>>>>>>> any further > >>>>>>>>>>>>>>>> action". > >>>>>>>>>>>>>>> This seems wrong to me. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think that the remedy to these is in the=20 > verifier. The=20 > >>>>>>>>>>>>>>> purpose of the verifier is ultimately to drive an=20 > >>>>>>>>>>>>>>> authorization > >>>>>> decision. If > >>>>>>>>>>>>>>> authorization would succeed in the absence of the > >>>>>>>>>>>>> identity, then the > >>>>>>>>>>>>>>> request should be permitted to continue as if the=20 > >>>>>>>>>>>>>>> identity was not present. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Unfortunately this would seem to require a revision to > >>>>>>>>>>>>>>> 4474 even though the paint is hardly dry on it. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> If this is done, then there is no need of a=20 > mechanism to > >>>>>>>>>>>> cause the > >>>>>>>>>>>>>>> authentication service *not* to authenticate.=20 > If this is > >>>>>>>>>>>>> *not* done, > >>>>>>>>>>>>>>> then that need remains, which will still require a > >>>>>>>>>>>> change to 4474. > >>>>>>>>>>>>>>> Paul > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Sip mailing list=20 > >>>>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/sip > >>>>>>>>>>>>>>> This list is for NEW development of the core SIP=20 > >>>>>>>>>>>>>>> Protocol Use sip-implementors@cs.columbia.edu for=20 > >>>>>>>>>>>>>>> questions on > >>>>>>>>>> current sip > >>>>>>>>>>>>>>> Use sipping@ietf.org for new developments on the > >>>>>>>>>>>> application of sip > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> 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 > >>>>>> 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 >=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 Oct 18 10:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC8r-00043K-25; Wed, 18 Oct 2006 10:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaC8p-000431-EK for sip@ietf.org; Wed, 18 Oct 2006 10:11:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaC8m-0005jg-3J for sip@ietf.org; Wed, 18 Oct 2006 10:11:31 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2006 07:11:27 -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 k9IEBRHU029637; Wed, 18 Oct 2006 07:11:27 -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 k9IEBJbV019249; Wed, 18 Oct 2006 07:11:23 -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, 18 Oct 2006 10:11:22 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:11:22 -0400 Message-ID: <45363609.6090206@cisco.com> Date: Wed, 18 Oct 2006 10:11:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] Recent List of all SIP headers in IANA registry References: <5D1A7985295922448D5550C94DE2918062566E@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918062566E@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 14:11:22.0309 (UTC) FILETIME=[4A228750:01C6F2BF] DKIM-Signature: a=rsa-sha1; q=dns; l=2006; t=1161180687; x=1162044687; 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]=20Recent=20List=20of=20all=20SIP=20headers=20in=20IANA=20r egistry; X=v=3Dcisco.com=3B=20h=3DCijX7ylz3SfngiEa7U2s8TlnxNo=3D; b=jdbl4HBpc9Eobrza4sTBKNguXN2wGGpMffKAw84wXG0i9t6UYOy3S+sESRkoowKwGqEk37Bv zGbQYxdf0f0bTjtpVx3D2tDnPSO26y3tjsvzgkurn3poOIKL6wS5lh/C; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) 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 Note that the registry only reflects those headers defined in RFCs. Proposals for new headers, appearing in drafts that haven't yet made RFC, aren't listed anywhere. It would be nice if there were some way to have drafts reflected in the registry, with appropriate indication. But that would probably be too much work for IANA. Paul Drage, Keith (Keith) wrote: > The IANA registry is externally visible: > > http://www.iana.org/numbers.html > > and search for Session Initiation Protocol (SIP) Parameters > > Specifically they are at: > > http://www.iana.org/assignments/sip-parameters > > The purpose of RFC 3968 and RFC 3969 was to create these registries so > IANA could continue to populate them from the IANA considerations > sections of subsequent published documents (in accordance with the rules > provided). > > Regards > > Keith > > > ________________________________ > > From: Vasudeva M [mailto:vasudeva.manjunath@gmail.com] > Sent: 18 October 2006 10:30 > To: sip@ietf.org > Subject: [Sip] Recent List of all SIP headers in IANA registry > > > Hi All, > > I wanted to know whether there is ANY Central place to see > currently IANA Registered SIP Headers... > I checked out rfc3968 which gives all the SIP Headers in IANA > Registry. > The RFC was itself published in 2004. I could not find any other > update to this RFC. > > I would like to get the Latest list of all the SIP Headers in > the IANA registry and the corresponding RFCs/drafts... > Any pointers would be really helpful. (google didn't help much > though...) > > Thanks and Best Regards, > Vasu > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 18 10:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCP7-0007xt-W7; Wed, 18 Oct 2006 10:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCP6-0007xm-Co for sip@ietf.org; Wed, 18 Oct 2006 10:28:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCP0-0000P2-0k for sip@ietf.org; Wed, 18 Oct 2006 10:28:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 07:28:14 -0700 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 k9IESC70014531; Wed, 18 Oct 2006 10:28:12 -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 k9IESCYJ017287; Wed, 18 Oct 2006 10:28:12 -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, 18 Oct 2006 10:28:12 -0400 Received: from [161.44.55.215] ([161.44.55.215]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:28:12 -0400 Message-ID: <453639FC.6000003@cisco.com> Date: Wed, 18 Oct 2006 10:28:12 -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: "Jesske, R" Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments References: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 14:28:12.0055 (UTC) FILETIME=[A3FD8A70:01C6F2C1] DKIM-Signature: a=rsa-sha1; q=dns; l=3345; t=1161181692; x=1162045692; 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]draft-rosenberg-sip-identity-coexistence-00.txt=20further=0 A=20comments |To:=22Jesske,=20R=22=20; X=v=3Dcisco.com=3B=20h=3De8TXhHv3a4V9XbDxJi3Og0gzWC8=3D; b=CeKY8dhD2HyuONbuyznlYVoO+mKN/FAC+2Z21eXvbSy2wyNsv8cCcQ8MyImqKDl7N5dYB+4j b8calYAC0W8Hp15XKHSqd8JsVMtpRf5ZU5WqJp5O0UD0tagKFgQhE5EC; 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: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, this harkens back to my rant during the last IETF meeting. My point was that this usage of both P-A-ID and From you are describing is not the semantics implied by RFC 3325 or RFC 3261, but rather a "decision" by 3gpp, ITU and others to use PAID as a billing identity. Indeed I quote RFC 3325: 9.1 The P-Asserted-Identity Header The P-Asserted-Identity header field is used among trusted SIP entities (typically intermediaries) to carry the identity of the user sending a SIP message as it was verified by authentication. To me, the "identity of the user sending a SIP message" is NOT the "identity of the entity that will be billed for this request". It means as it says - it is the identity of the *user* that *sent* the request. Quoting from RFC 3261: 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. These are identical definitions, the only difference being the term 'logical', which is implied I think in any system that assigns identities to users. I would like to understand how one can interpret these texts to mean that P-A-ID is a billing identity while From is the user's identity. -Jonathan R. Jesske, R wrote: > Dear all, > With regard to the following section I have some concerns regarding the > thought use of the P-Asserted-Identity. > > 4.3. Ingress Proxy > > .... If the identity > is verified, the ingress proxy SHOULD insert a P-Asserted-ID header > field containing the identity contained in the From header field of > the request. The proxy SHOULD NOT remove the Identity and Identity- > Info header fields. This allows for SIP networks where there are > more than two administrative domains in a request path, and also > allows for a UA to verify the signature on its own if it should > desire.... > > This will violate the use of the From and P-Asserted-Identity header > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping > with the PSTN. > > The P-Asserted-Identity is used as a public ID that is trusted. The From > header is set by the user itself and is untrusted. So that there is the > possibility to have two different identities within one INVITE. > To equalise such identities within a B2BUA at the ingress even if the >>From is also a now secure and trusted ID. > > Within the NGN this two identities are used for PBX services to present > the main PBX number and a individual extension of the PBX. > > Also the deletion and re-inclusion is against the rules of the RFC3325. > The destination domain is not allowed to change the identity of the > originating domain. > > If such procedures will be done also charging and billing mechanisms > used between domains will be violated. because the P-Asserted-Identity > is the base identity of the origin domain on Billing and charging. > > Best Regards > > Roland > -- 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 Oct 18 10:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCQ7-0008JL-PQ; Wed, 18 Oct 2006 10:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCQ6-0008JF-De for sip@ietf.org; Wed, 18 Oct 2006 10:29:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCQ2-0000es-Vn for sip@ietf.org; Wed, 18 Oct 2006 10:29:22 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2006 07:29:19 -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 k9IETIvi018144; Wed, 18 Oct 2006 07:29:18 -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 k9IET6bN026910; Wed, 18 Oct 2006 07:29:18 -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); Wed, 18 Oct 2006 10:29:13 -0400 Received: from [161.44.55.215] ([161.44.55.215]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:29:13 -0400 Message-ID: <45363A3A.5060802@cisco.com> Date: Wed, 18 Oct 2006 10:29:14 -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: Vasudeva M Subject: Re: [Sip] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.txt References: <62B9B0847CC47543B6B3B5E26BD268E60E84F9F8@zrc2hxm2.corp.nortel.com> <453548E5.2080707@cisco.com> <60ac91480610180254t78dce64co1bb4be8cd1cb9330@mail.gmail.com> In-Reply-To: <60ac91480610180254t78dce64co1bb4be8cd1cb9330@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 14:29:13.0634 (UTC) FILETIME=[C8B1C020:01C6F2C1] DKIM-Signature: a=rsa-sha1; q=dns; l=2430; t=1161181758; x=1162045758; 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]=20Re=3A=20A=20Comment=20draft-ietf-sip-hitchhikers-guide-0 0.txt; X=v=3Dcisco.com=3B=20h=3DLoLhw1XfZfi5HqxV/Ftq8ssgo40=3D; b=g4F0/XiH4vnAo61/jyygEmjcf4ECDTTG/wc0U1rsg4FLi2VgnQlJR4/5TutQ4v4Bev48NTyF E76sEL8vKxAL503+KjbamFoHZnv2R8KsoSZOra6KlEN7XBvZsorCtRH6; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Well, as you say, the current scope of the guide is only extensions, SIP objects, and SDP and extensions targeted specifically for SIP. Including informational documents makes this into a massive bloat. I would rather keep the current scope. -Jonathan R. Vasudeva M wrote: > Hi, > > Would it be OK if the references (RFC3968 and RFC3969) which lists > currently IANA registered SIP headers(and URI parameters) are included > in hitchhikers' guide ? (even though it does not extend/modify the SIP > protocol.) > > Regards, > Vasu > > > > On 10/18/06, *Jonathan Rosenberg* > wrote: > > THanks for the comments, and apologies for the slow response. See below. > > Samir Srivastava wrote: > > > Hi, > > > > > > > > 1) Shouldn't we have reference to the open bugs in this > guide in > > some form. Atleast a reference to bugzilla web site? > > That is not within the scope of this document. There is ongoing > discussion on what to do with those bugs, no conclusion yet. But this > document serves only to enumerate the SIP specifications. > > > > > > > > > 2) It refers the RFC 2976 for SIP INFO. Shouldn't it refer > the RFC > > 2833 there. We may be widening its scope to media too.. > > INFO is an existing normative extension to SIP and so it is referenced. > That doesn't mean we are proposing it be used for DTMF; it just means > its an extension. RFC 2833 is not a SIP extension, it is an RTP > extension. So it is not included. > > > -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 Wed Oct 18 10:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCXV-0002i8-Ra; Wed, 18 Oct 2006 10:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCXT-0002hz-Su for sip@ietf.org; Wed, 18 Oct 2006 10:36:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCXS-0001nS-Mb for sip@ietf.org; Wed, 18 Oct 2006 10:36:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 07:36:58 -0700 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 k9IEaw18018741; Wed, 18 Oct 2006 10:36:58 -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 k9IEasDW027614; Wed, 18 Oct 2006 10:36:58 -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, 18 Oct 2006 10:36:57 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:36:57 -0400 Message-ID: <45363C08.8040106@cisco.com> Date: Wed, 18 Oct 2006 10:36:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" Subject: Re: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 comments) References: <5D1A7985295922448D5550C94DE291806258C9@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291806258C9@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 14:36:57.0068 (UTC) FILETIME=[DCEC2AC0:01C6F2C2] DKIM-Signature: a=rsa-sha1; q=dns; l=33263; t=1161182218; x=1162046218; 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]=20RE=3A=20Rejecting=20connected=20identity=20(was=20RE=3A= 20draft-ietf-sip-connecte=0A=20d-id=20entity-01=20comments) |To:=22Drage,=20Keith=20\(Keith\)=22=20; X=v=3Dcisco.com=3B=20h=3DC2jXf3+A2AvuO27+qMJKQ3q+DaU=3D; b=Aj6Ym07ZHHy9dRQd9Gr1+ePS3y2ylSEvo5aqlajiWHVVYWBV3bp/9OWmrpXHT9P6dV+Co/qY bm5Cs9QTgnUC5ek3goZUuu8ZrrdCzqg+3DFHxZEdgMiUhHAn8Yy0wExT; 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: 942a2239d4a6506347d099a4d907f6bf Cc: Cullen Jennings , Jon Peterson , SIP , "Elwell, John" , 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 I guess I no longer know exactly what behavior is being proposed. I thought we were talking about a verifier that would add P-A-ID corresponding to an identity that it has successfully verified. I don't see how *that* causes any problems. Did someone also talk about removing P-A-ID? If there are other mechanisms for inserting P-A-ID, then there are some possible interactions: - if the verification fails, and there is *already* a P-A-ID present for the identity being verified, then if the verifier removes that P-A-ID then some problems may result. - if the verification succeeds, and there is already a P-A-ID with some *different* sip identity, then the verifier must remove that old identity if it is to add one reflecting the new identity. These problems can be defined away by saying that in both of these cases the verifier should not modify the existing P-A-ID. However that may blunt the value of the verifier. This kind specification for how to handle the interaction probably doesn't belong in an ietf document. It seems like a policy for a particular trust domain. A draft could state that in these cases the verifier should act in accord with local policy. Paul Drage, Keith (Keith) wrote: > I would suggest the problem is not the making of the new assertion. > > The issue is the removal of the assertion that some other entity made, > that may be equally valid. > > Note that this may particularly be an issue in emergency calls, where > PSAPs object to the removal of any information about the user (correct > or incorrect), and in some countries, they may want to believe the > asserter in the trust domain before they believe the user and his > certificate server owner. > > Regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 18 October 2006 14:09 >> To: shida@ntt-at.com >> Cc: Cullen Jennings; SIP; Elwell,John; Jon Peterson; Dan Wing >> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >> draft-ietf-sip-connecte d-id entity-01 comments) >> >> >> >> Shida Schubert wrote: >>> Although using P-A-ID may look like a good approach for >> this, I don't >>> know if it's really a good idea as it seems to change the >> semantics of >>> P-A-ID. >> I don't think this *is* changing the semantics of P-A-ID. >> >> The semantics are very simple: something in the trust domain >> determines the identity of the message and inserts to header >> for the benefit of others in the trust domain. The entity >> doing the assertion has full latitude about how it determines >> the identity it asserts. >> >> What this is doing is providing a new way to make that determination. >> The new way may not be appropriate in all environments, and >> that's fine. >> >>> Also, it may generates some issues when P-A-ID already >> exists in the >>> message along with connected-identity. >> That part needs to be clarified. >> >>> Following illustrates potential problems. >>> >>> connected-id(FROM): carol@b.com >>> P-A-ID: carol@b.com >>> >>> Now, following the proposal by John when Case 2 is deployed, and >>> assuming the verification of identity failed, it will still forward >>> the message as it is if we allow Case 2. >> I guess here you are assuming: >> - the P-A-ID was present before the verifier got the message >> - the verifier leaves it in the message when verification fails >> >> These are assumptions about the interaction of preexisting >> P-A-ID and connected identity verification. There is an issue >> there, but there are other possible answers to it. >> >>> When UAS receives the request >>> it will see both the identity-info/header and P-A-ID with the value >>> equivalent to the value in the FROM header.. If UAS has no >> ability to >>> verify the signature itself, it will assume that the verification >>> worked. P-A-ID looks like a good place to indicate the >> success of the >>> verification but it might need something else. >> IMO the presence of the P-A-ID is not evidence that the >> verification worked. It is merely in indication that someone >> in the trust domain asserted this identity. It could be >> because the verification of the Identity worked, or because >> some other kind of authentication worked, or it could be >> because some bogus party within the trust domain lied. >> >> If you choose to trust the P-A-ID, it means you choose to >> believe in the trust model. Nothing more. >> >>> As for Cullen's comments. I agree with Paul here, if the security >>> policy at the verification side would allow request without >> identity, >>> it should forward the request even if the verification fails. >>> >>> Lastly, if P-A-ID value is used in some context, changing the value >>> may cause some problem as well(Assuming P-A-ID was there but a >>> different value from FROM value > verifier after >> verification succeeds >>> change the P-A-ID value to that of FROM). >>> >>> Regards >>> Shida >>> >>> Paul Kyzivat wrote: >>>> Cullen Jennings wrote: >>>>> I'm generally on board with things like you are >> suggesting below and >>>>> what is suggested in draft-rosenberg-sip-identity-coexistence. >>>>> However, I want to think very carefully about the security >>>>> properties of not rejecting things that failed based on security >>>>> properties - I'm not sure what I think of this yet. >>>>> >>>>> Any time you allow a security action that failed to >> continue sending >>>>> the request downstream, you run the risk that something >> further down >>>>> stream assumes that the security action worked because it >> must have >>>>> happened upstream. Clearly from a security point of view >> it would be >>>>> better not to have upstream elements do the security >> validation for >>>>> a downstream element but we did decide long ago that when doing >>>>> Identity we were going to allow for this so that we could migrate >>>>> from UAs that do not support Identity to system that does. >>>>> >>>>> So let me flip this around the other way and ask - do we >> really need >>>>> to allow for a request that failed verification to not >> result in an >>>>> error? >>>> I think the poster child for this is when the error is 437 >>>> Unsupported Certificate. >>>> >>>> In this case the caller may be trapped. It has an identity >> service it >>>> can't control, that unconditionally adds an identity. And then the >>>> callee has an authentication verifier in front of it. As things >>>> stand, that verifier is required to reject requests with certs it >>>> doesn't understand, even in cases where it will permit >> requests with >>>> no identity at all. >>>> >>>> Paul >>>> >>>>> Are there use cases where the verification would fail and >> we really >>>>> do want to continue with the message? If these cases would only >>>>> happen in a fairly broken system, then it might not be worth the >>>>> security problems they would cause. I don't know what I >> think but I >>>>> am interested in where we might need this and if there might be >>>>> other ways to skin the cat in those situations. >>>>> >>>>> Cullen >>>>> >>>>> >>>>> On Oct 10, 2006, at 6:20 AM, Paul Kyzivat wrote: >>>>> >>>>>> John, >>>>>> >>>>>> What you outline below is exactly what I had in mind. >>>>>> >>>>>> Paul >>>>>> >>>>>> Elwell, John wrote: >>>>>>> Paul, >>>>>>> Dan Wing made a suggestion that P-Asserted-Identity >> would fulfil >>>>>>> your requirement. I guess it would work like this. >>>>>>> A Verifier not located at the UAS would attempt to verify the >>>>>>> signature in the Identity header field. >>>>>>> - Case A - verification succeeds. The Verifier inserts into the >>>>>>> forwarded request a P-Asserted-Identity header field containing >>>>>>> the verified URI (from the From header field) in the forwarded >>>>>>> request. The Identity and Identity-Info header fields >> will still >>>>>>> be present and available should another verifier be encountered >>>>>>> downstream. >>>>>>> - Case B - verification fails but request not rejected. The >>>>>>> verifier is unable to verify (e.g., because it can't >> dereference >>>>>>> the URL) but according to policy does not reject the >> request. It >>>>>>> simply forwards the request as is. >>>>>>> If there is a further verifier downstream, that too can >> attempt to >>>>>>> verify the signature. >>>>>>> - Case C - verification fails but request is rejected. The >>>>>>> verifier is unable to verify (e.g., bad signature) and >> according >>>>>>> to policy it rejects the request. >>>>>>> A UAS that does not contain a verifier can simply use >>>>>>> P-Asserted-Identity, if present. >>>>>>> This seems to have some synergy with >>>>>>> draft-rosenberg-sip-identity-coexistence. In fact the >> relaxation >>>>>>> of rules concerning rejection by a verifier that is unable to >>>>>>> verify a signature might be beneficial to that proposal. >>>>>>> I will omit discussion of the mechanics of >> documentation until I >>>>>>> see what reaction there is to the technical proposal. >>>>>>> John >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 09 October >>>>>>>> 2006 13:54 >>>>>>>> To: Elwell, John >>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Elwell, John wrote: >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> Your message arrived just after I had submitted 02, so your >>>>>>>> comments are not >>>>>>>>> taken into account in that version. However, I felt it was >>>>>>>> useful to get 02 >>>>>>>>> out as a baseline for further discussion. >>>>>>>> Sure. I too am interested in seeing other inputs on >> this subject. >>>>>>>>> It seems the remaining issue is whether to add an explicit >>>>>>>> indication of >>>>>>>>> removal of the Identity header field by a verifier that has >>>>>>>> been unable to >>>>>>>>> verify the signature. Whilst this may make sense, I am >>>>>>>> concerned it starts >>>>>>>>> to go beyond the scope of connected-identity, so I would like >>>>>>>>> other opinions, especially from the chairs and from >> the authors >>>>>>>> of Identity. >>>>>>>> >>>>>>>> Rather than adding something to indicate that identity has been >>>>>>>> *removed* due to failure to verify, I am advocating adding >>>>>>>> something to indicate that verification has *succeeded*, while >>>>>>>> leaving the identity header in place. In this way, a >> downstream >>>>>>>> element may *either* trust the info added by the >> verifier or do >>>>>>>> its own verification of the identity header. >>>>>>>> >>>>>>>> Of course this is only significant if the verifier is >> doing work >>>>>>>> for downstream elements, and not for itself. >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: >> 05 October >>>>>>>>>> 2006 16:29 >>>>>>>>>> To: Elwell, John >>>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected identity (was RE: >>>>>>>>>> draft-ietf-si p-connecte d-id entity-01 comments) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Elwell, John wrote: >>>>>>>>>>> Paul, >>>>>>>>>>> >>>>>>>>>>> So your proposal is that the connected-identity RFC should >>>>>>>>>> update RFC 4474 >>>>>>>>>>> to somehow relax rules at a verifier. Correct? >>>>>>>>>> Yeah, I think so. >>>>>>>>>> >>>>>>>>>>> So the next question concerns the way in which these >>>>>>>> rules should be >>>>>>>>>>> relaxed. One problem with the verifier not being located at >>>>>>>>>> the UAS but at >>>>>>>>>>> some proxy is that the UAS might be configured always to >>>>>>>>>> trust identities >>>>>>>>>>> received in requests via the verifier's proxy if an >>>>>>>>>> Identity header field is >>>>>>>>>>> present, on the assumption that the signature has been >>>>>>>>>> checked by the >>>>>>>>>>> verifier. Therefore it sounds like the verifier, if it does >>>>>>>>>> not reject a >>>>>>>>>>> request with a bad signature, should remove the Identity >>>>>>>>>> header field (and >>>>>>>>>>> also Identity-Info) before forwarding the request towards >>>>>>>>>> the target. >>>>>>>>>> >>>>>>>>>> (I think I have seen someone propose combining the use of >>>>>>>>>> Identity and P-Asserted-Identity, though I don't recall the >>>>>>>>>> details, or which draft it was. So what I am about >> to say might >>>>>>>>>> bear no >>>>>>>> relationship to that.) >>>>>>>>>> I could see how Identity might be used between trust >>>>>>>> domains, while >>>>>>>>>> P-Asserted-Identity is used within a trust domain. In that >>>>>>>>>> case, a verifier might run at the entry point to a >> trust domain >>>>>>>>>> and if verification succeeds, insert a P-Asserted-Identity >>>>>>>>>> header with a corresponding identity. It then might, >> or might >>>>>>>>>> not, remove the Identity header. Recipients within the trust >>>>>>>>>> domain could then use P-Asserted-Identity as the source of >>>>>>>>>> identity info. (In this scenario, an identity header >> would only >>>>>>>>>> be added to requests when they leave the trust domain.) >>>>>>>>>> >>>>>>>>>> In this kind of environment, it is only necessary for the >>>>>>>> verifier to >>>>>>>>>> omit the P-Asserted-Identity header when verification fails. >>>>>>>>>> >>>>>>>>>>> Under what conditions should a verifier remove an Identity >>>>>>>>>> header field >>>>>>>>>>> rather than rejecting with 436/437/438? My inclination >>>>>>>>>> would be to leave it >>>>>>>>>>> as a matter of policy as far as the update to RFC 4474 is >>>>>>>>>> concerned, and >>>>>>>>>>> then make more precise statements concerning >> mid-dialog requests. >>>>>>>>>>> Alternatively the update to RFC 4474 could just relax the >>>>>>>> rules for >>>>>>>>>>> mid-dialog requests. I think there is some merit in >>>>>>>>>> relaxing the rules in >>>>>>>>>>> general, because otherwise there might be situations where >>>>>>>>>> a legitimate >>>>>>>>>>> caller cannot establish a call because an Authentication >>>>>>>>>> Service (outside >>>>>>>>>>> the UAC's control) is inserting an unverifiable signature >>>>>>>> (e.g., in >>>>>>>>>>> Identity-Info placing a URL that the Verifier cannot >>>>>>>>>> dereference for some >>>>>>>>>>> reason). >>>>>>>>>> What you say sounds reasonable to me. >>>>>>>>>> >>>>>>>>>> There is however some risk to having a verifier remove >>>>>>>> identity. The >>>>>>>>>> problem would be when there are potentially multiple >>>>>>>> verifiers that >>>>>>>>>> don't trust one another. If an early one removes the >>>>>>>> header, then it >>>>>>>>>> prevents a subsequent verifier from doing its own >> verification. >>>>>>>>>> This could come up if a request transits a domain on >> the way to >>>>>>>>>> another domain. Each domain may wish to do its own >> verification. >>>>>>>>>> That is an advantage to having the verifier add something to >>>>>>>>>> the request to indicate the result of its verification. >>>>>>>>>> >>>>>>>>>>> One consequence of the Verifier being separated from the >>>>>>>>>> UAS is that we >>>>>>>>>>> don't want to rely on stateful behaviour at the Verifier or >>>>>>>>>> its proxy (for >>>>>>>>>>> similar reasons that you cited for the Authentication >>>>>>>>>> Service earlier). So >>>>>>>>>>> for mid-dialog requests we would need to mandate, or at >>>>>>>>>> least recommend, >>>>>>>>>>> that 436/437/438 should not be sent. >>>>>>>>>> Right. >>>>>>>>>> >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>>> John >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 03 >>>>>>>>>>>> October 2006 01:44 >>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>> Cc: Cullen Jennings; Jon Peterson; SIP >>>>>>>>>>>> Subject: Re: [Sip] RE: Rejecting connected >> identity (was RE: >>>>>>>>>>>> draft-ietf-sip-connecte d-id entity-01 comments) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>> Thinking further on this, perhaps there is a 4th way: >>>>>>>>>>>>> >>>>>>>>>>>>> 4. Specify that if a UAS rejects a mid-dialog request with >>>>>>>>>>>> 436, 437 or 438, >>>>>>>>>>>>> then it MUST NOT invoke the verifier for a subsequent >>>>>>>>>>>>> request >>>>>>>>>>>> This assumes that the verifier is invoked by the UAS, and >>>>>>>>>> not by some >>>>>>>>>>>> proxy in front of the UAS. Isn't it valid to have >> a verifier >>>>>>>>>>>> in a proxy before the UAS? This rule would forbid that, >>>>>>>>>>>> because it would cause that proxy to be call stateful. >>>>>>>>>>>> >>>>>>>>>>>> I think it would just be better to update the RFC, even >>>>>>>>>>>> though that is a bit more trouble than not to. >>>>>>>>>>>> >>>>>>>>>>>> Paul >>>>>>>>>>>> >>>>>>>>>>>>> on the same >>>>>>>>>>>>> dialog unless the From header field URI has >> changed, and in >>>>>>>>>>>> such cases >>>>>>>>>>>>> SHOULD NOT make use of the unverified connected-identity. >>>>>>>>>>>> Then a UAC, on >>>>>>>>>>>>> receiving 436, 437 or 438, MUST repeat the request once. >>>>>>>>>>>> This would allow >>>>>>>>>>>>> business as usual on this dialog (but without the benefit >>>>>>>>>>>> of connected >>>>>>>>>>>>> identity, therefore no worse than at present). It avoids >>>>>>>>>>>> any change to RFC >>>>>>>>>>>>> 4474, because verification is optional anyway. >>>>>>>>>>>>> >>>>>>>>>>>>> Would this work? >>>>>>>>>>>>> >>>>>>>>>>>>> John >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Elwell, John Sent: 26 September 2006 21:02 >>>>>>>>>>>>>> To: Cullen Jennings; Jon Peterson >>>>>>>>>>>>>> Cc: SIP; Paul Kyzivat >>>>>>>>>>>>>> Subject: FW: Rejecting connected identity (was RE: >>>>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cullen, Jon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> In case you missed this (it wasn't addressed directly to >>>>>>>>>>>>>> you), I would greatly appreciate an opinion from each of >>>>>>>>>>>>>> you on this remaining issue in >> connected-identity. Just to >>>>>>>>>>>>>> summarise, RFC 4474 leaves it up to policy whether to >>>>>>>>>>>>>> return a 428 response if Identity is missing, >> but mandates >>>>>>>>>>>>>> the sending of a 436, 437 or 438 response for certain >>>>>>>>>>>>>> errors arising while verifying the signature. It >> seems that >>>>>>>>>>>>>> for mid dialog requests this behaviour could be harmful. >>>>>>>>>>>>>> What does the UAC for the mid dialog request do if it >>>>>>>>>>>>>> receives 436, >>>>>>>>>>>>>> 437 or 438? If the mid-dialog request was solely for the >>>>>>>>>>>>>> purpose of connected identity, it can give up >> and allow the >>>>>>>>>>>>>> call to continue as is. But if the request was for some >>>>>>>>>>>>>> other purpose (e.g., renegotiating the session >> because of >>>>>>>>>>>>>> hold, say, or session timer refresh), the UAC >> really wants >>>>>>>>>>>>>> it to work. For the normal case where the Authentication >>>>>>>>>>>>>> Service is at a proxy, not at the UAC, the UAC >> cannot force >>>>>>>>>>>>>> the Authentication Service to refrain from putting this >>>>>>>>>>>>>> unverifiable signature in the mid-dialog request, so any >>>>>>>>>>>>>> attempts to repeat the request would most likely >> be doomed >>>>>>>>>>>>>> to getting the same response. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems there are three things we could do, none very >>>>>>>>>> attractive: >>>>>>>>>>>>>> 1. Get connected-identity to modify the procedures of RFC >>>>>>>>>>>>>> 4474 for a verifier by softening the requirements for >>>>>>>>>>>>>> sending 436, 437 and 438 in response to >> mid-dialog requests. >>>>>>>>>>>>>> But then a mid-dialog request from a rogue >> source would be >>>>>>>>>>>>>> accepted. >>>>>>>>>>>>>> 2. Say that the Authentication Service should omit the >>>>>>>>>>>>>> signing of mid-dialog requests if a previous attempt has >>>>>>>>>>>>>> resulted in 436, 437 or 438. But this implies >> statefulness >>>>>>>>>>>> at the AS. >>>>>>>>>>>>>> 3. Accept the fact the mid-dialog requests can >> fail in this >>>>>>>>>>>>>> way and therefore things like session refresh >> and session >>>>>>>>>>>>>> renegotiation cannot be done, probably resulting in call >>>>>>>>>>>>>> failure. Sounds bad, but it is no different from >> an initial >>>>>>>>>>>>>> INVITE request, where there is nothing the UAC can do if >>>>>>>>>>>>>> the AS inserts an Identity header that gets >> rejected with >>>>>>>>>>>>>> 436, >>>>>>>>>>>> 437 or 438. >>>>>>>>>>>>>> John >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>>>> September 2006 19:26 >>>>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>>>> Subject: Re: Rejecting connected identity (was RE: >>>>>>>>>>>>>>> draft-ietf-sip-connected-id entity-01 comments) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> John, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I want to hear what others, especially Jon and Cullen, >>>>>>>>>>>>>>> have to say about this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is of some concern to me that a call might fail >>>>>>>>>>>> because of some >>>>>>>>>>>>>>> problem with the identity mechanism when the same call >>>>>>>>>> might have >>>>>>>>>>>>>>> succeeded in the absence of any identity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But possibly the solution to this is policy in the >>>>>>>>>>>>>>> implementation of the verifier. What to do in >> the case of >>>>>>>>>>>>>>> the conditions that >>>>>>>>>>>>>> lead to these >>>>>>>>>>>>>>> errors could be configurable in the verifier: either to >>>>>>>>>>>>>> generate the >>>>>>>>>>>>>>> error or simply to remove the identity info from the >>>>>>>>>>>>>> message. And the >>>>>>>>>>>>>>> policy could conceivably vary based on >> attributes of the >>>>>>>>>>>>>>> message, such as whether it is in-dialog or not. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does it require a change to 4474 to permit that kind >>>>>>>> of policy? >>>>>>>>>>>>>>> It would be annoying if the end user had no >> control over >>>>>>>>>>>>>>> the insertion and verification of identity, and it >>>>>>>>>>>>>>> resulted in calls failing that the user would like to >>>>>>>>>>>>>>> permit. But I suppose that is itself >>>>>>>>>> a policy >>>>>>>>>>>>>>> decision. There are certainly enterprises that want to >>>>>>>>>>>>>>> exert that kind of control over what users are >> permitted >>>>>>>>>>>>>>> to do. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Paul >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>>> Paul, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I agree with most of your points, and on reflection I >>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>> I agree that the >>>>>>>>>>>>>>>> solution has to be with the verifier. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think RFC 4474 is not a problem as far as >> sending a 428 >>>>>>>>>>>>>>> 'Use Identity >>>>>>>>>>>>>>>> Header' response is concerned, because that is left to >>>>>>>>>>>>>>> policy, so we could >>>>>>>>>>>>>>>> say in connected-identity that policy should be to not >>>>>>>>>> send 428. >>>>>>>>>>>>>>>> However, 436, 437 and 438 responses are all a problem, >>>>>>>>>>>>>>> because RFC 4474 says >>>>>>>>>>>>>>>> that they MUST be sent under respective conditions. >>>>>>>>>>>>>>> Interestingly, though, >>>>>>>>>>>>>>>> there are other failure scenarios that can >> arise from the >>>>>>>>>>>>>>> procedures of >>>>>>>>>>>>>>>> section 6 of RFC 4474 for which no normative >> statement is >>>>>>>>>>>>>>> given on how to >>>>>>>>>>>>>>>> respond, e.g. invalid Date header field, signer not >>>>>>>>>>>>>>> authoritative for the >>>>>>>>>>>>>>>> domain. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So one way to solve the present problem would >> be for the >>>>>>>>>>>>>>> connected-identity >>>>>>>>>>>>>>>> draft to modify verifier behaviour in RFC 4474 in the >>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>> of mid-dialog >>>>>>>>>>>>>>>> requests. I guess this would mean that it would update >>>>>>>>>>>>>>>> RFC >>>>>>>>>>>>>>> 4474 as well as >>>>>>>>>>>>>>>> updating RFC 3261. But I don't like this, because it >>>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>> to remove some of >>>>>>>>>>>>>>>> the security properties of RFC 4474. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Another way would be to accept that 436, 437 and 438 >>>>>>>>>>>>>>> responses will be sent, >>>>>>>>>>>>>>>> and failure to verify a signature will >> therefore result >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> inability to >>>>>>>>>>>>>>>> process the UPDATE or re-INVITE request, and >> hence if the >>>>>>>>>>>>>> UPDATE or >>>>>>>>>>>>>>>> re-INVITE request was for some other purpose such as >>>>>>>>>>>>>>> session timer refresh >>>>>>>>>>>>>>>> or modifying the session, that action will >> fail. Then the >>>>>>>>>>>>>>> call will fail (in >>>>>>>>>>>>>>>> the case of inability to refresh the session timer) or >>>>>>>>>>>> the session >>>>>>>>>>>>>>>> modification will fail. I guess this is somewhat >>>>>>>>>>>>>>>> analogous >>>>>>>>>>>>>>> to caller ID >>>>>>>>>>>>>>>> verification failure in an INVITE request - it is >>>>>>>>>>>>>>> impossible to establish a >>>>>>>>>>>>>>>> call if verification fails. Moreover, the UAC has no >>>>>>>>>>>>>>> ability to rectify the >>>>>>>>>>>>>>>> situation, since it is at the mercy of a proxy-based >>>>>>>>>>>>>>> Authentication Service >>>>>>>>>>>>>>>> that puts a rogue Identity header field in >> every request. >>>>>>>>>>>>>>> In the connected >>>>>>>>>>>>>>>> identity case, the only difference is that the call is >>>>>>>>>>>>>>> already established >>>>>>>>>>>>>>>> but is likely to fail if verification fails. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course, if the mid-dialog request is indeed from the >>>>>>>>>>>>>>> wrong source, then >>>>>>>>>>>>>>>> sending a 436, 437 or 438 response is indeed >> the correct >>>>>>>>>>>>>>> thing to do, and >>>>>>>>>>>>>>>> overriding the verification procedures of RFC >> 4474 would >>>>>>>>>>>>>>> indeed be the wrong >>>>>>>>>>>>>>>> thing to do. So perhaps we just have to accept >> that these >>>>>>>>>>>>>>> response codes can >>>>>>>>>>>>>>>> be received and will lead to failure. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So, my preferred way forward is simply to recommend not >>>>>>>>>>>>>>> sending a 428 and >>>>>>>>>>>>>>>> accept the consequences of other responses that the >>>>>>>>>>>>>>> verifier might send. >>>>>>>>>>>>>>>> John >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: Paul Kyzivat >> [mailto:pkyzivat@cisco.com] Sent: 22 >>>>>>>>>>>>>>>>> September 2006 15:13 >>>>>>>>>>>>>>>>> To: Elwell, John >>>>>>>>>>>>>>>>> Cc: Cullen Jennings; SIP >>>>>>>>>>>>>>>>> Subject: Re: [Sip] RE: >>>>>>>>>>>>>>> draft-ietf-sip-connected-identity-01 comments >>>>>>>>>>>>>>>>> Elwell, John wrote: >>>>>>>>>>>>>>>>>>> From: Cullen Jennings >> [mailto:fluffy@cisco.com] When >>>>>>>>>>>>>>>>>>> an Update is sent. Are there any conditions >>>>>>>>>> under which >>>>>>>>>>>>>>>>>>> it might be rejected. Bad identity for example. I >>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>> might need a >>>>>>>>>>>>>>>>>>> little discussion and also what the UA does when it >>>>>>>>>>>>>>>>>>> sends >>>>>>>>>>>>>>>>> an update >>>>>>>>>>>>>>>>>>> with a no identity and it gets rejected. >>>>>>>>>>>>>>>>>> [JRE] A very good point. We don't want to get to a >>>>>>>>>>>>>>>>> situation where it is >>>>>>>>>>>>>>>>>> impossible to perform a mid-dialog request (e.g., for >>>>>>>>>>>>>>>>> purposes such as >>>>>>>>>>>>>>>>>> session timer refresh or session re-negotiation) just >>>>>>>>>>>>>>>>> because connected >>>>>>>>>>>>>>>>>> identity fails. >>>>>>>>>>>>>>>>>> My proposed fix is as follows: >>>>>>>>>>>>>>>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog >>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>> with 428 'Use >>>>>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>>>>> I'm not sure about this. At the least I think this >>>>>>>> one needs >>>>>>>>>>>>>>>>> some clear explanation of the SHOULD NOT - about the >>>>>>>>>>>>>>>>> conditions when >>>>>>>>>>>>>>> it can be >>>>>>>>>>>>>>>>> violated. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I see this as somewhat analogous to doing a digest >>>>>>>>>>>>>> challenge on an >>>>>>>>>>>>>>>>> in-dialog request. In some cases it is the right >>>>>>>> thing to do. >>>>>>>>>>>>>>>>> A UA that imposes such a requirement will be >>>>>>>> limited in what >>>>>>>>>>>>>>>>> it can do, but that may still be right in some cases. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. Say that an Authentication Service MUST NOT add an >>>>>>>>>>>>>>>>> Identity header field >>>>>>>>>>>>>>>>>> to a mid-dialog request if a previous request on that >>>>>>>>>>>>>>>>> dialog has resulted in >>>>>>>>>>>>>>>>>> 436 'Bad Identity-Info', 437 'Unsupported >> Certificate' >>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>> 438 'Invalid >>>>>>>>>>>>>>>>>> Identity Header'. >>>>>>>>>>>>>>>>> This requirement would force the >> authentication service >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> be dialog >>>>>>>>>>>>>>>>> stateful, which is not ideal. Better to push the state >>>>>>>>>>>>>>> back into the >>>>>>>>>>>>>>>>> sender of the request. This may require a way for the >>>>>>>>>>>>>>>>> UAC >>>>>>>>>>>>>>> to tell the >>>>>>>>>>>>>>>>> authentication service not to act. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 3. Say that a UAC MUST repeat a mid-dialog >> request that >>>>>>>>>>>>>>>>> results in one of >>>>>>>>>>>>>>>>>> these responses if the mid-dialog request was not >>>>>>>>>>>>>>>>>> solely >>>>>>>>>>>>>>>>> for the purpose of >>>>>>>>>>>>>>>>>> connected identity. If solely for the purpose of >>>>>>>>>>>>>>>>>> connected >>>>>>>>>>>>>>>>> identity there is >>>>>>>>>>>>>>>>>> no point in repeating it, so I will say "SHOULD NOT >>>>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>> any further >>>>>>>>>>>>>>>>>> action". >>>>>>>>>>>>>>>>> This seems wrong to me. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think that the remedy to these is in the >> verifier. The >>>>>>>>>>>>>>>>> purpose of the verifier is ultimately to drive an >>>>>>>>>>>>>>>>> authorization >>>>>>>> decision. If >>>>>>>>>>>>>>>>> authorization would succeed in the absence of the >>>>>>>>>>>>>>> identity, then the >>>>>>>>>>>>>>>>> request should be permitted to continue as if the >>>>>>>>>>>>>>>>> identity was not present. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Unfortunately this would seem to require a revision to >>>>>>>>>>>>>>>>> 4474 even though the paint is hardly dry on it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If this is done, then there is no need of a >> mechanism to >>>>>>>>>>>>>> cause the >>>>>>>>>>>>>>>>> authentication service *not* to authenticate. >> If this is >>>>>>>>>>>>>>> *not* done, >>>>>>>>>>>>>>>>> then that need remains, which will still require a >>>>>>>>>>>>>> change to 4474. >>>>>>>>>>>>>>>>> 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 >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Oct 18 10:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaChd-0005wl-BG; Wed, 18 Oct 2006 10:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaChb-0005wd-Gp for sip@ietf.org; Wed, 18 Oct 2006 10:47:27 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaChU-0003bY-L7 for sip@ietf.org; Wed, 18 Oct 2006 10:47:27 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9IElJuM003941 for ; Wed, 18 Oct 2006 16:47:19 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9IElIAO028941 for ; Wed, 18 Oct 2006 16:47:18 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 16:47:17 +0200 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_01C6F2C4.48A674F0" Date: Wed, 18 Oct 2006 16:46:28 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Draft regarding SIP Identity Usage (draft-fries-sip-identity-usage-bcp-00.txt) Thread-Index: AcbyPxTP3EzqyIWASw6INW0J6++DngAg5UeA From: "Fries, Steffen" To: X-OriginalArrivalTime: 18 Oct 2006 14:47:17.0740 (UTC) FILETIME=[4EDF32C0:01C6F2C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Subject: [Sip] Draft regarding SIP Identity Usage (draft-fries-sip-identity-usage-bcp-00.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_01C6F2C4.48A674F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, we submitted a draft discussing a potential use case for SIP Identiy targeting a Best Current Practice approach.=20 The draft basically describes the usage of SIP identity to enable the protected submission of certificate material within a SIP request to a remote UA. The certificate material may belong to the user or to the device and may be short or long term. Using SIP Identity enables the receiver to assocciate the received certificate material with the authenticated identity and use it e.g. for a secure negotiation of further security parameter. Possible use cases comprise environments were no globally resolvable certificates are provided or were the certificate material available on the device may not be directly associated with the user of that device. The former version of the draft has been submitted and discussed within the SIPPING WG, but it was stated that this is rather a SIP topic. So we updated the draft and submitted this as initial version to the SIP WG. We would like to see if there is sufficient interest to bring this approach forward in the SIP WG. Regards Steffen -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, October 18, 2006 12:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-fries-sip-identity-usage-bcp-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Identity Usage Author(s) : S. Fries, et al. Filename : draft-fries-sip-identity-usage-bcp-00.txt Pages : 11 Date : 2006-10-17 =09 This document describes a use case for the SIP Identity document involving certificate, which may not be publically resolvable. It provides a best current practice document for binding an identity to a certificate for the duration of a session. The certificate may then be used to bootstrap further security parameters, e.g., for securing media data. A discussion of possible enhancements is included in the appendix. Editors Note: The first version of this draft was discussed in the SIPPING WG. As the target of this draft is a BCP for current issues, the draft was updated and submitted to the SIP WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fries-sip-identity-usage-bcp-0 0.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-fries-sip-identity-usage-bcp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-fries-sip-identity-usage-bcp-00.txt". =09 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_001_01C6F2C4.48A674F0 Content-Type: application/octet-stream; name="draft-fries-sip-identity-usage-bcp-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-fries-sip-identity-usage-bcp-00.URL Content-Disposition: attachment; filename="draft-fries-sip-identity-usage-bcp-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mcmllcy1zaXAtaWRlbnRpdHktdXNhZ2UtYmNwLTAwLnR4dA0K ------_=_NextPart_001_01C6F2C4.48A674F0 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_01C6F2C4.48A674F0-- From sip-bounces@ietf.org Wed Oct 18 10:59:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCqg-0002Zu-HW; Wed, 18 Oct 2006 10:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCqf-0002ZX-2y for sip@ietf.org; Wed, 18 Oct 2006 10:56:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCqb-0005JB-K5 for sip@ietf.org; Wed, 18 Oct 2006 10:56:49 -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 k9IEueg28975; Wed, 18 Oct 2006 10:56: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] Question on REGISTER Date: Wed, 18 Oct 2006 09:56:26 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110FF7941@zrc2hxm2.corp.nortel.com> In-Reply-To: <45362924.2070804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on REGISTER Thread-Index: Acbyt6HjRgtEsaoyQzyoWmpePQ1LKwADWDVA From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sip@ietf.org, CLHaft@aol.com, 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 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, October 18, 2006 8:16 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; sip@ietf.org; CLHaft@aol.com > Subject: Re: [Sip] Question on REGISTER >=20 >=20 >=20 > Brian Stucker wrote: > > IMHO-- > >=20 > > Having implemented registrars and things that register with them. > >=20 > > The RFC is designed to disallow registrations for the same target=20 > > resource at the registrar. This means that ANYONE trying to=20 > register=20 > > against a particular target resource at the registrar must=20 > wait their=20 > > turn and no overlapping is allowed (the target resource's=20 > contact set=20 > > is not allowed to change in parallel). Once the 200 OK to one=20 > > registration is sent out though, the next guy in the queue=20 > is free to do their thing. >=20 > Brian - are you saying that if two different UAs, X and Y,=20 > are attempting to register to the same AOR, Z, that they must=20 > coordinate with one another to prevent concurrent REGISTER requests? >=20 > How would you expect them to do so? >=20 > This is a serialization problem for the registrar, not the UAs. No, that's not what I'm saying. The UAs are ignorant of one another, the registrar has to queue up the requests. Sending back 491s to X or Y makes no sense since they're using different SIP transactions entirely (assuming they are). >=20 > > This doesn't mean that the registrar has to send a 491 back to=20 > > overlapping registrations from two different sources trying to=20 > > register for the same target resource in parallel as long=20 > as their SIP=20 > > transactions aren't overlapping. >=20 > overlapping how? Standard SIP overlapping transactions... Two transactions with the same SIP context information (callid, tags, etc) but the CSEQs are different and a final response hasn't been sent for the transaction with the lower CSEQ value when the transaction with the higher CSEQ is received. That'll earn you a 491 from the SIP transaction layer in most cases. >=20 > Paul >=20 > > You should only get a 491 if you have a pending=20 > registration with the=20 > > same SIP transaction context information (tags, callid,=20 > etc, matches a=20 > > registration that is still being processed). > >=20 > > BTW- You may want to have a systems engineer take a look at your=20 > > pacing algorithm. Depending on the timer intervals involved, you're=20 > > going to wind up with some wickedly sinusoidal traffic=20 > patterns from =20 > > most obvious traffic spreading algorithms. > >=20 > > Check that. > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, October 17, 2006 9:28 AM > >> To: Dean Willis > >> Cc: sip@ietf.org; CLHaft@aol.com > >> Subject: Re: [Sip] Question on REGISTER > >> > >> I do agree with Dean on this. > >> > >> I like the phrase "massive non-workingness". Another=20 > Dean-ism for the=20 > >> book. > >> > >> The server you are registering to has no business sending=20 > you a 491=20 > >> when you send a second REGISTER to a different AOR. But it=20 > certainly=20 > >> can send you a 503 if you are trying to send 4000 concurrent=20 > >> REGISTERs. > >> > >> Paul > >> > >> Dean Willis wrote: > >>> CLHaft@aol.com wrote: > >>>> I'm working on a gateway between a proprietary system and > >> SIP. One > >>>> of our new projects involves sending REGISTERs on behalf > >> of some of > >>>> our users to a third party server. They are pointing at section > >>>> 10.2 of RFC 3261 where it states: > >>>> > >>>> UAs MUST NOT send a new registration (that is, containing new=20 > >>>> Contact header field values, as opposed to a > >> retransmission) until > >>>> they have received a final response from the registrar for the=20 > >>>> previous one or the previous REGISTER request has timed out. > >>>> =20 > >>>> Does this really mean that our gateway must really wait for a=20 > >>>> response for one user before we can send a REGISTER for=20 > a second=20 > >>>> user? This is what we are being told by the third-party > >> vendor of > >>>> the registration server. I find it hard to believe that > >> this is the > >>>> intent of the RFC, especially since it allows for > >> stateless proxies > >>>> to be in the path, where they would not be able to do this. > >>> Paul is correct that this section 10.2 text really refers > >> to REGISTER > >>> requests with the same request-URI and To: value launched > >> by a single > >>> UA, and its intent is to prevent "stacking up" of pending=20 > requests=20 > >>> that are effectively going to cancel each other out anyhow. > >>> > >>> However, you may still want to do some sort of flow control > >> or pacing > >>> on a sequence of REGISTER requests. Many registrars will > >> fall over or > >>> at least get blocked up and start dropping requests if=20 > they're hit=20 > >>> with too many overlapping requests. This is why the "avalanche=20 > >>> restart" problem (where perhaps many UAs served by a single > >> registrar > >>> reset at the same time due to a power failure) is such a > >> big problem for large systems. > >>> Serializing the requests is probably the absolute safest > >> flow control > >>> model. Note that this places no real dependencies on > >> proxies, just on > >>> multiuser UAs. By serialization, I mean that the UA does > >> not start a > >>> new register request until it has received a 200 OK (or=20 > other final > >>> response) to the preceding request. > >>> > >>> More sophisticated systems might launch REGISTER requests at some=20 > >>> rate-per-second, with reasonable numbers for real=20 > hardware probably=20 > >>> ranging from 4 to 400. Certainly if you drop 4,000 registration=20 > >>> requests on a server within a 1-second window you are=20 > going to see=20 > >>> some massive not-workingness. > >>> > >>> > >>> -- > >>> Dean > >>> > >>> _______________________________________________ > >>> 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 >=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 Oct 18 11:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCsb-00038S-UJ; Wed, 18 Oct 2006 10:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCsa-00037T-Ec for sip@ietf.org; Wed, 18 Oct 2006 10:58:48 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCsZ-0005c6-23 for sip@ietf.org; Wed, 18 Oct 2006 10:58:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GaCsO-0006Nh-PN; Wed, 18 Oct 2006 09:58:37 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Jesske, R'" Subject: RE: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments Date: Wed, 18 Oct 2006 10:58:39 -0400 Message-ID: <005401c6f2c5$e6f84ff0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcbyudfM8qDJH3TgSe+YSNTiChD95QACuDhw In-Reply-To: <45362C6D.2000406@cisco.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: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "'Seibel, Matthias'" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 wondered about this myself. Further, I don't want to foster interdomain use of P-A-I without the kinds of "Trust Domain" specifications 3325 discusses. I think we have the problem now where most people ignore most of these issues in using P-A-I. I'm particularly distressed by the use of P-A-I to assert the Main Number. If we need such a facility, we should create one, and allow SIP Identity to validate it. I'd really like us to be thinking that we phase out P-A-I when Sip Identity is deployed. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, October 18, 2006 9:30 AM > To: Jesske, R > Cc: sip@ietf.org; Dieter.Jacobsohn@t-mobile.net; Seibel,Matthias > Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt > furthercomments > > Roland's comments below are a reflection of a general issue about the > semantics of identity that seems to be brewing. > > On one hand we have a set of people who are trying to restore the lost > usefulness of the From header, by providing a way to prove its validity > as an identity. > > On the other hand we have a different set of people who *like* the fact > that From is an unauthenticated assertion of identity, and want to keep > it that way. > > Or do I have the latter wrong? Maybe its ok if From gets authenticated > as long as there is still a way to have another asserted identity as well. > > Paul > > Jesske, R wrote: > > Dear all, > > With regard to the following section I have some concerns regarding the > > thought use of the P-Asserted-Identity. > > > > 4.3. Ingress Proxy > > > > .... If the identity > > is verified, the ingress proxy SHOULD insert a P-Asserted-ID header > > field containing the identity contained in the From header field of > > the request. The proxy SHOULD NOT remove the Identity and Identity- > > Info header fields. This allows for SIP networks where there are > > more than two administrative domains in a request path, and also > > allows for a UA to verify the signature on its own if it should > > desire.... > > > > This will violate the use of the From and P-Asserted-Identity header > > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping > > with the PSTN. > > > > The P-Asserted-Identity is used as a public ID that is trusted. The From > > header is set by the user itself and is untrusted. So that there is the > > possibility to have two different identities within one INVITE. > > To equalise such identities within a B2BUA at the ingress even if the > >>From is also a now secure and trusted ID. > > > > Within the NGN this two identities are used for PBX services to present > > the main PBX number and a individual extension of the PBX. > > > > Also the deletion and re-inclusion is against the rules of the RFC3325. > > The destination domain is not allowed to change the identity of the > > originating domain. > > > > If such procedures will be done also charging and billing mechanisms > > used between domains will be violated. because the P-Asserted-Identity > > is the base identity of the origin domain on Billing and charging. > > > > Best Regards > > > > Roland > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 Oct 18 11:03:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCvm-0005BK-Jf; Wed, 18 Oct 2006 11:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCvl-0005BF-ME for sip@ietf.org; Wed, 18 Oct 2006 11:02:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCvi-0007Gg-Al for sip@ietf.org; Wed, 18 Oct 2006 11:02:05 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2006 11:02:02 -0400 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 k9IF22Eo019472; Wed, 18 Oct 2006 11:02:02 -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 k9IF21DQ003944; Wed, 18 Oct 2006 11:02:01 -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, 18 Oct 2006 11:01:52 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 11:01:52 -0400 Message-ID: <453641DF.7000202@cisco.com> Date: Wed, 18 Oct 2006 11:01:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments References: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> <453639FC.6000003@cisco.com> In-Reply-To: <453639FC.6000003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 15:01:52.0344 (UTC) FILETIME=[582D2D80:01C6F2C6] DKIM-Signature: a=rsa-sha1; q=dns; l=4188; t=1161183722; x=1162047722; 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]draft-rosenberg-sip-identity-coexistence-00.txt=20further=0 A=20comments |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3D4594ZzISDxmDRiukQilYwyarxwY=3D; b=VbInpztctwsFiv3ipCjhm7sDeS0BeX2BlLMjOTSpBtXeGYcg0KplW0aY5s1tpq4n54EFHN/2 sbKBFntgH9H4MPMCWQjuKP77jqJzLPi0YbDJM4epcrBqtiS09pB51xiP; 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: a8a20a483a84f747e56475e290ee868e Cc: "Jesske, R" , sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I'm sorry. This draft *does* talk about removing the P-A-ID. I was thinking of the discussion about connected identity which has been loosely associated with this. What this draft doesn't do is relate its use of P-A-ID with the Privacy header, and specifically Privacy:id. The action it specifies for an egress proxy can cause the P-A-ID to be removed in cases where a proxy conforming to 3325 would leave it in. I am inclined to agree with Jonathan about how things ought to work. But I do think it can be arranged so that the two approaches can be made to coexist. Its all a matter of defining a suitable policy around the interaction of these two mechanisms. If an egress proxy (P-CSCF) discovers that P-A-ID doesn't match From, and if there is no Privacy:id header, it can simply leave P-A-ID in the requeest. If an ingress proxy finds a P-A-ID and the message is received from a source it trusts, it could leave that in the message and not attempt to verify any Identity header. Paul Jonathan Rosenberg wrote: > Well, this harkens back to my rant during the last IETF meeting. My > point was that this usage of both P-A-ID and From you are describing is > not the semantics implied by RFC 3325 or RFC 3261, but rather a > "decision" by 3gpp, ITU and others to use PAID as a billing identity. > > Indeed I quote RFC 3325: > > 9.1 The P-Asserted-Identity Header > > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity of the user > sending a SIP message as it was verified by authentication. > > > To me, the "identity of the user sending a SIP message" is NOT the > "identity of the entity that will be billed for this request". It means > as it says - it is the identity of the *user* that *sent* the request. > > Quoting from RFC 3261: > > 8.1.1.3 From > > The From header field indicates the logical identity of the initiator > of the request, possibly the user's address-of-record. > > > These are identical definitions, the only difference being the term > 'logical', which is implied I think in any system that assigns > identities to users. > > I would like to understand how one can interpret these texts to mean > that P-A-ID is a billing identity while From is the user's identity. > > -Jonathan R. > > > Jesske, R wrote: > >> Dear all, >> With regard to the following section I have some concerns regarding the >> thought use of the P-Asserted-Identity. >> >> 4.3. Ingress Proxy >> >> .... If the identity >> is verified, the ingress proxy SHOULD insert a P-Asserted-ID header >> field containing the identity contained in the From header field of >> the request. The proxy SHOULD NOT remove the Identity and Identity- >> Info header fields. This allows for SIP networks where there are >> more than two administrative domains in a request path, and also >> allows for a UA to verify the signature on its own if it should >> desire.... >> >> This will violate the use of the From and P-Asserted-Identity header >> within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping >> with the PSTN. >> >> The P-Asserted-Identity is used as a public ID that is trusted. The From >> header is set by the user itself and is untrusted. So that there is the >> possibility to have two different identities within one INVITE. >> To equalise such identities within a B2BUA at the ingress even if the >>> From is also a now secure and trusted ID. >> >> Within the NGN this two identities are used for PBX services to present >> the main PBX number and a individual extension of the PBX. >> >> Also the deletion and re-inclusion is against the rules of the RFC3325. >> The destination domain is not allowed to change the identity of the >> originating domain. >> >> If such procedures will be done also charging and billing mechanisms >> used between domains will be violated. because the P-Asserted-Identity >> is the base identity of the origin domain on Billing and charging. >> >> Best Regards >> >> Roland >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 18 11:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDX-0004qh-5i; Wed, 18 Oct 2006 11:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDU-0004pt-Um for sip@ietf.org; Wed, 18 Oct 2006 11:20:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCzD-00087i-Mc for sip@ietf.org; Wed, 18 Oct 2006 11:05:42 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 08:05:39 -0700 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 k9IF5dXg020692; Wed, 18 Oct 2006 11:05:39 -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 k9IF5cDU004649; Wed, 18 Oct 2006 11:05:39 -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, 18 Oct 2006 11:05:37 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 11:05:36 -0400 Message-ID: <453642C0.2090302@cisco.com> Date: Wed, 18 Oct 2006 11:05:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments References: <005401c6f2c5$e6f84ff0$640fa8c0@cis.neustar.com> In-Reply-To: <005401c6f2c5$e6f84ff0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 15:05:36.0897 (UTC) FILETIME=[DE053F10:01C6F2C6] DKIM-Signature: a=rsa-sha1; q=dns; l=4357; t=1161183939; x=1162047939; 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]draft-rosenberg-sip-identity-coexistence-00.txt=20furtherco mments |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3DI4YaEfODnT18BdCF8mv5iwp6ihU=3D; b=DDHJfMLYEFvvSXqqVi+rTTRGUMghCAs6GmuLAREb0n60Zushvecm6vZrL0DtrZ8b5S1zG00m JMl/YYbMMxf9s+uzBy72usUhOlefB17gXVAETAmap/TAzAlLzFhrZ08C; 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: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "'Jesske, R'" , sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "'Seibel, Matthias'" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Rosen wrote: > I've wondered about this myself. > > Further, I don't want to foster interdomain use of P-A-I without the kinds > of "Trust Domain" specifications 3325 discusses. I think we have the > problem now where most people ignore most of these issues in using P-A-I. > > I'm particularly distressed by the use of P-A-I to assert the Main Number. > If we need such a facility, we should create one, and allow SIP Identity to > validate it. > > I'd really like us to be thinking that we phase out P-A-I when Sip Identity > is deployed. While this sounds nice in theory, I'm concerned that the computational cost of using this will be prohibitive for some time to come. If it can be restricted to inter-domain calls then the cost is reduced, on average. But I don't have any hard performance numbers on this, so I am willing to be convinced otherwise. Paul > Brian > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, October 18, 2006 9:30 AM >> To: Jesske, R >> Cc: sip@ietf.org; Dieter.Jacobsohn@t-mobile.net; Seibel,Matthias >> Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt >> furthercomments >> >> Roland's comments below are a reflection of a general issue about the >> semantics of identity that seems to be brewing. >> >> On one hand we have a set of people who are trying to restore the lost >> usefulness of the From header, by providing a way to prove its validity >> as an identity. >> >> On the other hand we have a different set of people who *like* the fact >> that From is an unauthenticated assertion of identity, and want to keep >> it that way. >> >> Or do I have the latter wrong? Maybe its ok if From gets authenticated >> as long as there is still a way to have another asserted identity as well. >> >> Paul >> >> Jesske, R wrote: >>> Dear all, >>> With regard to the following section I have some concerns regarding the >>> thought use of the P-Asserted-Identity. >>> >>> 4.3. Ingress Proxy >>> >>> .... If the identity >>> is verified, the ingress proxy SHOULD insert a P-Asserted-ID header >>> field containing the identity contained in the From header field of >>> the request. The proxy SHOULD NOT remove the Identity and Identity- >>> Info header fields. This allows for SIP networks where there are >>> more than two administrative domains in a request path, and also >>> allows for a UA to verify the signature on its own if it should >>> desire.... >>> >>> This will violate the use of the From and P-Asserted-Identity header >>> within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the mapping >>> with the PSTN. >>> >>> The P-Asserted-Identity is used as a public ID that is trusted. The From >>> header is set by the user itself and is untrusted. So that there is the >>> possibility to have two different identities within one INVITE. >>> To equalise such identities within a B2BUA at the ingress even if the >>> >From is also a now secure and trusted ID. >>> >>> Within the NGN this two identities are used for PBX services to present >>> the main PBX number and a individual extension of the PBX. >>> >>> Also the deletion and re-inclusion is against the rules of the RFC3325. >>> The destination domain is not allowed to change the identity of the >>> originating domain. >>> >>> If such procedures will be done also charging and billing mechanisms >>> used between domains will be violated. because the P-Asserted-Identity >>> is the base identity of the origin domain on Billing and charging. >>> >>> Best Regards >>> >>> Roland >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 Oct 18 11:33:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDNd-0005fE-Jt; Wed, 18 Oct 2006 11:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDNc-0005Xt-1r for sip@ietf.org; Wed, 18 Oct 2006 11:30:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDNY-0004Sr-DB for sip@ietf.org; Wed, 18 Oct 2006 11:30:52 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 18 Oct 2006 08:30:48 -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 k9IFUlUK022860; Wed, 18 Oct 2006 08:30:47 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9IFUlbF002278; Wed, 18 Oct 2006 08:30:47 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn5-667.cisco.com [10.21.90.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9IFIlU3017514; Wed, 18 Oct 2006 08:18:47 -0700 Message-ID: <453648A6.2080105@cisco.com> Date: Wed, 18 Oct 2006 08:30:46 -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: Paul Kyzivat References: <005401c6f2c5$e6f84ff0$640fa8c0@cis.neustar.com> <453642C0.2090302@cisco.com> In-Reply-To: <453642C0.2090302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-8.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=5357; t=1161185447; x=1162049447; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:!; X=v=3Dcisco.com=3B=20h=3Dr4+1vy+OZTMYZEFtnPZkktfXcRY=3D; b=w4tiZvbc3fPdYRNhZHJdX15Skw1P5Y/7pKWdpftDpEVsdBB7btiwdOp7v7Iu/2U3cbaXXUgX JAqCMxXevIWGp0oWl3m7ydZlstuptTkU4gXN9DrnIvC5afmFSwhi+Z2y; X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: "'Jesske, R'" , sip@ietf.org, "'Seibel, Matthias'" , Dieter.Jacobsohn@t-mobile.net Subject: [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 Paul Kyzivat wrote: > > > Brian Rosen wrote: > >> I've wondered about this myself. >> >> Further, I don't want to foster interdomain use of P-A-I without the >> kinds >> of "Trust Domain" specifications 3325 discusses. I think we have the >> problem now where most people ignore most of these issues in using >> P-A-I. >> >> I'm particularly distressed by the use of P-A-I to assert the Main >> Number. >> If we need such a facility, we should create one, and allow SIP >> Identity to >> validate it. >> >> I'd really like us to be thinking that we phase out P-A-I when Sip >> Identity >> is deployed. > > > While this sounds nice in theory, I'm concerned that the computational > cost of using this will be prohibitive for some time to come. If it > can be restricted to inter-domain calls then the cost is reduced, on > average. But I don't have any hard performance numbers on this, so I > am willing to be convinced otherwise. I can't speak for the actual complexity of sip-identity, but I have a lot of experience with DKIM which is similar computationally. Moore's Law has basically made this a non-issue. At Cisco, we've deployed DKIM internally to sign all of our mail and the cost/mail is minimal cpu-wise. We likely could have deployed on our existing hardware as Y! did for their deployment of DK, but it was easier/safer to isolate it into its own boxen that drove that decision, not the cpu cost. Mike > > Paul > >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Wednesday, October 18, 2006 9:30 AM >>> To: Jesske, R >>> Cc: sip@ietf.org; Dieter.Jacobsohn@t-mobile.net; Seibel,Matthias >>> Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt >>> furthercomments >>> >>> Roland's comments below are a reflection of a general issue about the >>> semantics of identity that seems to be brewing. >>> >>> On one hand we have a set of people who are trying to restore the lost >>> usefulness of the From header, by providing a way to prove its validity >>> as an identity. >>> >>> On the other hand we have a different set of people who *like* the fact >>> that From is an unauthenticated assertion of identity, and want to keep >>> it that way. >>> >>> Or do I have the latter wrong? Maybe its ok if From gets authenticated >>> as long as there is still a way to have another asserted identity as >>> well. >>> >>> Paul >>> >>> Jesske, R wrote: >>> >>>> Dear all, >>>> With regard to the following section I have some concerns regarding >>>> the >>>> thought use of the P-Asserted-Identity. >>>> >>>> 4.3. Ingress Proxy >>>> >>>> .... If the identity >>>> is verified, the ingress proxy SHOULD insert a P-Asserted-ID header >>>> field containing the identity contained in the From header field of >>>> the request. The proxy SHOULD NOT remove the Identity and >>>> Identity- >>>> Info header fields. This allows for SIP networks where there are >>>> more than two administrative domains in a request path, and also >>>> allows for a UA to verify the signature on its own if it should >>>> desire.... >>>> >>>> This will violate the use of the From and P-Asserted-Identity header >>>> within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the >>>> mapping >>>> with the PSTN. >>>> >>>> The P-Asserted-Identity is used as a public ID that is trusted. The >>>> From >>>> header is set by the user itself and is untrusted. So that there is >>>> the >>>> possibility to have two different identities within one INVITE. >>>> To equalise such identities within a B2BUA at the ingress even if the >>>> >From is also a now secure and trusted ID. >>>> >>>> Within the NGN this two identities are used for PBX services to >>>> present >>>> the main PBX number and a individual extension of the PBX. >>>> >>>> Also the deletion and re-inclusion is against the rules of the >>>> RFC3325. >>>> The destination domain is not allowed to change the identity of the >>>> originating domain. >>>> >>>> If such procedures will be done also charging and billing mechanisms >>>> used between domains will be violated. because the P-Asserted-Identity >>>> is the base identity of the origin domain on Billing and charging. >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 Wed Oct 18 11:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDOa-0007A3-Lk; Wed, 18 Oct 2006 11:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDOZ-00079H-Ce for sip@ietf.org; Wed, 18 Oct 2006 11:31:51 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDOX-0004gx-1r for sip@ietf.org; Wed, 18 Oct 2006 11:31:51 -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 k9IFVgd13969; Wed, 18 Oct 2006 11:31: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] Question on REGISTER Date: Wed, 18 Oct 2006 10:31:41 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110FF7A56@zrc2hxm2.corp.nortel.com> In-Reply-To: <4536465A.20301@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on REGISTER Thread-Index: AcbyyQ3ocdoab4k9QCC1A8kgNdoWLgAAJoug From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org, CLHaft@aol.com, 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 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, October 18, 2006 10:21 AM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; sip@ietf.org; CLHaft@aol.com > Subject: Re: [Sip] Question on REGISTER > >>> This doesn't mean that the registrar has to send a 491 back to=20 > >>> overlapping registrations from two different sources trying to=20 > >>> register for the same target resource in parallel as long > >> as their SIP > >>> transactions aren't overlapping. > >> overlapping how? > >=20 > > Standard SIP overlapping transactions... Two transactions with the=20 > > same SIP context information (callid, tags, etc) but the CSEQs are=20 > > different and a final response hasn't been sent for the transaction=20 > > with the lower CSEQ value when the transaction with the=20 > higher CSEQ is received. > > That'll earn you a 491 from the SIP transaction layer in most cases. >=20 > I don't interpret this the same way that you do. >=20 > AFAIK that isn't a transaction layer issue at all. This is in=20 > fact ok in some cases. For instance it is legal to send a 2nd=20 > NOTIFY before the response has been received for an earlier=20 > one. (Often not wise, but > legal.) And if you have two dialog usages sharing a dialog,=20 > you might have a NOTIFY and a reINVITE overlap. >=20 You shouldn't allow overlapping REGISTER transactions on the same 'dialog' using UDP (and typically an end device shouldn't try to circumvent this by sending them on different 'dialogs') because you have no idea which one will arrive at the registrar first. If the application registering doesn't care which one is processed first, then it's at least safe. However, if the registrar doesn't wish to provide internal queueing of requests, a 491 isn't the worst return code you could come up with to push the work to the clients. Regards, 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 Oct 18 11:42:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDWq-0002gS-I4; Wed, 18 Oct 2006 11:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDWo-0002fD-8v for sip@ietf.org; Wed, 18 Oct 2006 11:40:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaDWl-0007lh-Od for sip@ietf.org; Wed, 18 Oct 2006 11:40:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 08:40:20 -0700 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 k9IFeJ1N015243; Wed, 18 Oct 2006 11:40:19 -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 k9IFeJDM014956; Wed, 18 Oct 2006 11:40:19 -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); Wed, 18 Oct 2006 11:40:19 -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]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments Date: Wed, 18 Oct 2006 11:40:18 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E30211F653@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments Thread-Index: AcbywfQoptaHH7JrRTSlt6VPYxBTUQACX4ZA From: "Michael Hammer \(mhammer\)" To: "Jonathan Rosenberg \(jdrosen\)" , "Jesske, R" X-OriginalArrivalTime: 18 Oct 2006 15:40:19.0374 (UTC) FILETIME=[B74604E0:01C6F2CB] DKIM-Signature: a=rsa-sha1; q=dns; l=4655; t=1161186019; x=1162050019; 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]draft-rosenberg-sip-identity-coexistence-00.txt=20furtherco mments |To:=22Jonathan=20Rosenberg=20\(jdrosen\)=22=20, =0A=20=20 =20=20=20=20=20=20=22Jesske,=20R=22=20; X=v=3Dcisco.com=3B=20h=3DArIz0+bPop6HC2j0AGWpGT8mrts=3D; b=S5WA9ZDuJZ3iourNVSdSC0c5Fdc7UCz2lQ4NDOnO7SRy0OET6XvWaLghBLHc04w858GE8k83 2gUe93MPH6igbNb8Dilfm4m9P9tidoZ1Hv5FPAJEVZkgdjpA7pKJDT/9; 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: 22bbb45ef41b733eb2d03ee71ece8243 Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, The text seems to be saying that the PAID must take the value of the From, even though it may be bogus, and where the trust domain can determine form other means the true identity of the sender. The problem is in forcing PAID to conform to whatever the sender put in the From. Mike =20 > -----Original Message----- > From: Jonathan Rosenberg (jdrosen)=20 > Sent: Wednesday, October 18, 2006 10:28 AM > To: Jesske, R > Cc: sip@ietf.org; Dieter.Jacobsohn@t-mobile.net; Seibel,Matthias > Subject: Re:=20 > [Sip]draft-rosenberg-sip-identity-coexistence-00.txt furthercomments >=20 > Well, this harkens back to my rant during the last IETF=20 > meeting. My point was that this usage of both P-A-ID and From=20 > you are describing is not the semantics implied by RFC 3325=20 > or RFC 3261, but rather a "decision" by 3gpp, ITU and others=20 > to use PAID as a billing identity. >=20 > Indeed I quote RFC 3325: >=20 > 9.1 The P-Asserted-Identity Header >=20 > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity=20 > of the user > sending a SIP message as it was verified by authentication. >=20 >=20 > To me, the "identity of the user sending a SIP message" is=20 > NOT the "identity of the entity that will be billed for this=20 > request". It means as it says - it is the identity of the=20 > *user* that *sent* the request. >=20 > Quoting from RFC 3261: >=20 > 8.1.1.3 From >=20 > The From header field indicates the logical identity of=20 > the initiator > of the request, possibly the user's address-of-record. >=20 >=20 > These are identical definitions, the only difference being=20 > the term 'logical', which is implied I think in any system=20 > that assigns identities to users. >=20 > I would like to understand how one can interpret these texts=20 > to mean that P-A-ID is a billing identity while From is the=20 > user's identity. >=20 > -Jonathan R. >=20 >=20 > Jesske, R wrote: >=20 > > Dear all, > > With regard to the following section I have some concerns regarding=20 > > the thought use of the P-Asserted-Identity. > >=20 > > 4.3. Ingress Proxy > >=20 > > .... If the identity > > is verified, the ingress proxy SHOULD insert a=20 > P-Asserted-ID header > > field containing the identity contained in the From=20 > header field of > > the request. The proxy SHOULD NOT remove the Identity=20 > and Identity- > > Info header fields. This allows for SIP networks where there are > > more than two administrative domains in a request path, and also > > allows for a UA to verify the signature on its own if it should > > desire.... > >=20 > > This will violate the use of the From and=20 > P-Asserted-Identity header=20 > > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN including the=20 > > mapping with the PSTN. > >=20 > > The P-Asserted-Identity is used as a public ID that is trusted. The=20 > > From header is set by the user itself and is untrusted. So=20 > that there=20 > > is the possibility to have two different identities within=20 > one INVITE. > > To equalise such identities within a B2BUA at the ingress=20 > even if the > >>From is also a now secure and trusted ID. > >=20 > > Within the NGN this two identities are used for PBX services to=20 > > present the main PBX number and a individual extension of the PBX. > >=20 > > Also the deletion and re-inclusion is against the rules of=20 > the RFC3325. > > The destination domain is not allowed to change the identity of the=20 > > originating domain. > >=20 > > If such procedures will be done also charging and billing=20 > mechanisms=20 > > used between domains will be violated. because the=20 > P-Asserted-Identity=20 > > is the base identity of the origin domain on Billing and charging. > >=20 > > Best Regards > >=20 > > Roland > >=20 >=20 > --=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=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 Oct 18 13:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEoI-0003YB-JA; Wed, 18 Oct 2006 13:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEoH-0003UP-Cs for sip@ietf.org; Wed, 18 Oct 2006 13:02:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEoE-0001A7-0v for sip@ietf.org; Wed, 18 Oct 2006 13:02:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2006 13:02:26 -0400 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 k9IH2P8A023863; Wed, 18 Oct 2006 13:02:25 -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 k9IH2PYJ005898; Wed, 18 Oct 2006 13:02:25 -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, 18 Oct 2006 13:02:25 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 13:02:24 -0400 Message-ID: <45365E21.10201@cisco.com> Date: Wed, 18 Oct 2006 13:02:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [Sip] Question on REGISTER References: <6FC4416DDE56C44DA0AEE67BC7CA437110FF7A56@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110FF7A56@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 17:02:24.0877 (UTC) FILETIME=[2F1A21D0:01C6F2D7] DKIM-Signature: a=rsa-sha1; q=dns; l=2587; t=1161190945; x=1162054945; 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=20on=20REGISTER |To:Brian=20Stucker=20; X=v=3Dcisco.com=3B=20h=3DyDooipuEhcCESUaMNqXytABoo9o=3D; b=PbOyuAvJ5Tw1LXf5IUOTeBFSrDOJyjIxNovlmJGXbn1AxRWM+oPP0a2UneVBoPpLSR00PCLQ b816O3fpK1i4M1UP23FkUi8orNEdAh6UcQPpmxkA11JzW9i3tDjl82dC; 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, CLHaft@aol.com, 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 Brian Stucker wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, October 18, 2006 10:21 AM >> To: Stucker, Brian (RICH1:AR00) >> Cc: Dean Willis; sip@ietf.org; CLHaft@aol.com >> Subject: Re: [Sip] Question on REGISTER >>>>> This doesn't mean that the registrar has to send a 491 back to >>>>> overlapping registrations from two different sources trying to >>>>> register for the same target resource in parallel as long >>>> as their SIP >>>>> transactions aren't overlapping. >>>> overlapping how? >>> Standard SIP overlapping transactions... Two transactions with the >>> same SIP context information (callid, tags, etc) but the CSEQs are >>> different and a final response hasn't been sent for the transaction >>> with the lower CSEQ value when the transaction with the >> higher CSEQ is received. >>> That'll earn you a 491 from the SIP transaction layer in most cases. >> I don't interpret this the same way that you do. >> >> AFAIK that isn't a transaction layer issue at all. This is in >> fact ok in some cases. For instance it is legal to send a 2nd >> NOTIFY before the response has been received for an earlier >> one. (Often not wise, but >> legal.) And if you have two dialog usages sharing a dialog, >> you might have a NOTIFY and a reINVITE overlap. >> > > You shouldn't allow overlapping REGISTER transactions on the same > 'dialog' using UDP (and typically an end device shouldn't try to > circumvent this by sending them on different 'dialogs') because you have > no idea which one will arrive at the registrar first. If the application > registering doesn't care which one is processed first, then it's at > least safe. Note that there is only a conflict when the AOR and the Contact being registered are the same. When different contacts are being registered (which is usually the case for registers from different sources) the only race condition is about which contacts that weren't in the register will be returned in the response. > However, if the registrar doesn't wish to provide internal queueing of > requests, a 491 isn't the worst return code you could come up with to > push the work to the clients. IMO a registrar which returns a 491 as a result of concurrent registrations that target different AORs or that have different contact values and different Call-ID values, is broken. In the case that initiated this, I believe the registers were to different AORs, but came over the same TCP connection. 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 Oct 18 13:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEvu-0007AO-LE; Wed, 18 Oct 2006 13:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEvt-0007AG-4V for sip@ietf.org; Wed, 18 Oct 2006 13:10:21 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEvp-00039e-PW for sip@ietf.org; Wed, 18 Oct 2006 13:10:21 -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 k9IHAB120574; Wed, 18 Oct 2006 13:10:11 -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] Question on REGISTER Date: Wed, 18 Oct 2006 12:10:10 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437110FF7CFE@zrc2hxm2.corp.nortel.com> In-Reply-To: <45365E21.10201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Question on REGISTER Thread-Index: Acby1zNX1cU3AzV5QIC4rBlqlGgLAQAALqBQ From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org, CLHaft@aol.com, 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 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, October 18, 2006 12:02 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; sip@ietf.org; CLHaft@aol.com > Subject: Re: [Sip] Question on REGISTER >=20 >=20 >=20 > Brian Stucker wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, October 18, 2006 10:21 AM > >> To: Stucker, Brian (RICH1:AR00) > >> Cc: Dean Willis; sip@ietf.org; CLHaft@aol.com > >> Subject: Re: [Sip] Question on REGISTER > >>>>> This doesn't mean that the registrar has to send a 491 back to=20 > >>>>> overlapping registrations from two different sources trying to=20 > >>>>> register for the same target resource in parallel as long > >>>> as their SIP > >>>>> transactions aren't overlapping. > >>>> overlapping how? > >>> Standard SIP overlapping transactions... Two transactions=20 > with the=20 > >>> same SIP context information (callid, tags, etc) but the=20 > CSEQs are=20 > >>> different and a final response hasn't been sent for the=20 > transaction=20 > >>> with the lower CSEQ value when the transaction with the > >> higher CSEQ is received. > >>> That'll earn you a 491 from the SIP transaction layer in=20 > most cases. > >> I don't interpret this the same way that you do. > >> > >> AFAIK that isn't a transaction layer issue at all. This is=20 > in fact ok=20 > >> in some cases. For instance it is legal to send a 2nd=20 > NOTIFY before=20 > >> the response has been received for an earlier one. (Often=20 > not wise,=20 > >> but > >> legal.) And if you have two dialog usages sharing a=20 > dialog, you might=20 > >> have a NOTIFY and a reINVITE overlap. > >> > >=20 > > You shouldn't allow overlapping REGISTER transactions on the same=20 > > 'dialog' using UDP (and typically an end device shouldn't try to=20 > > circumvent this by sending them on different 'dialogs') because you=20 > > have no idea which one will arrive at the registrar first. If the=20 > > application registering doesn't care which one is processed first,=20 > > then it's at least safe. >=20 > Note that there is only a conflict when the AOR and the=20 > Contact being registered are the same. When different=20 > contacts are being registered (which is usually the case for=20 > registers from different sources) the only race condition is=20 > about which contacts that weren't in the register will be=20 > returned in the response. That's right. >=20 > > However, if the registrar doesn't wish to provide internal=20 > queueing of=20 > > requests, a 491 isn't the worst return code you could come=20 > up with to=20 > > push the work to the clients. >=20 > IMO a registrar which returns a 491 as a result of concurrent=20 > registrations that target different AORs or that have=20 > different contact values and different Call-ID values, is broken. >=20 I'd agree that it's definitely very sub-optimal, but I don't see how it breaks things. It is rather annoying though. > In the case that initiated this, I believe the registers were=20 > to different AORs, but came over the same TCP connection. That definitely sounds like a bad implementation issue then. The TCP connection reuse shouldn't have anything to do with sending a 491 back. >=20 > Paul >=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 Oct 18 13:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFXo-0006W5-PV; Wed, 18 Oct 2006 13:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFXn-0006Tj-EP for sip@ietf.org; Wed, 18 Oct 2006 13:49:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFXi-0003Kb-Te for sip@ietf.org; Wed, 18 Oct 2006 13:49:31 -0400 Received: from [64.101.181.232] (dhcp-64-101-181-232.cisco.com [64.101.181.232]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9IGqdZh013533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Oct 2006 11:52:40 -0500 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437110FF752E@zrc2hxm2.corp.nortel.com> References: <6FC4416DDE56C44DA0AEE67BC7CA437110FF752E@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <097BC499-C050-4928-B636-00928975BB36@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Question on REGISTER Date: Wed, 18 Oct 2006 12:49:15 -0500 To: Brian Stucker X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Paul Kyzivat , CLHaft@aol.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 Oct 17, 2006, at 9:44 PM, Brian Stucker wrote: > > BTW- You may want to have a systems engineer take a look at your > pacing > algorithm. Depending on the timer intervals involved, you're going to > wind up with some wickedly sinusoidal traffic patterns from most > obvious traffic spreading algorithms. > That's for sure. I believe the underlying problem is isomorphic to the TCP rate-control problem, and look at the complexity that fine- tuning that has involved over the years. Fortunately it sounds like there are a relatively limited number of "senders" in this scenario, so that reduces the complexity a bit. But there's still plenty of room for rate-adaptive techniques like "slow start" and "transaction count windowing" and other stuff straight out of TCP. One could certainly do a thesis project on optimizing the scnnario if one were so inclined. -- 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 Oct 18 13:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFep-0004bs-6j; Wed, 18 Oct 2006 13:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFen-0004bj-IU for sip@ietf.org; Wed, 18 Oct 2006 13:56:45 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFem-0004mv-7y for sip@ietf.org; Wed, 18 Oct 2006 13:56:45 -0400 Received: from [64.101.181.232] (dhcp-64-101-181-232.cisco.com [64.101.181.232]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9IGxrUH013627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Oct 2006 11:59:54 -0500 In-Reply-To: <45362C6D.2000406@cisco.com> References: <85108216918A984C8C60172D7C84770A56F7A7@S4DE8PSAAGO.mitte.t-com.de> <45362C6D.2000406@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DD6B212-82CD-44BC-A6B8-55C2D6C7ACF2@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments Date: Wed, 18 Oct 2006 12:56:29 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Jesske, R" , sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 18, 2006, at 8:30 AM, Paul Kyzivat wrote: > Roland's comments below are a reflection of a general issue about > the semantics of identity that seems to be brewing. > > On one hand we have a set of people who are trying to restore the > lost usefulness of the From header, by providing a way to prove its > validity as an identity. > > On the other hand we have a different set of people who *like* the > fact that From is an unauthenticated assertion of identity, and > want to keep it that way. > > Or do I have the latter wrong? Maybe its ok if From gets > authenticated as long as there is still a way to have another > asserted identity as well. > > Paul > I'd like to assert that a third camp exists -- those who feel that From: and To: have gotten so confabulated that it is best to populate them with random haiku. I believe this relates back to the usage of From and To tags and transaction matching rules. Once we moved transport-state into these application-layer features, we greatly reduced their utility from an application perspective. Something on my wish list for sip 3.0 . . . -- 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 Oct 18 14:05:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFlG-0008JF-V4; Wed, 18 Oct 2006 14:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFlF-0008J7-F6 for sip@ietf.org; Wed, 18 Oct 2006 14:03:25 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFlA-0005vK-P9 for sip@ietf.org; Wed, 18 Oct 2006 14:03:25 -0400 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Oct 2006 20:03:19 +0200 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 20:03:18 +0200 Content-class: urn:content-classes:message Subject: AW: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 18 Oct 2006 20:03:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85108216918A984C8C60172D7C84770A56F7AD@S4DE8PSAAGO.mitte.t-com.de> X-MimeOLE: Produced By Microsoft Exchange V6.5 in-reply-to: <453639FC.6000003@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments Thread-Index: AcbywpgZWlhNPo58TTWKnbJP3ZEdWQACUdIg From: "Jesske, R" To: X-OriginalArrivalTime: 18 Oct 2006 18:03:18.0820 (UTC) FILETIME=[B1059640:01C6F2DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 would like to understand how one can interpret these texts to mean=20 > that P-A-ID is a billing identity while From is the user's identity. The P-A-ID is per definition within 3GPP the public user identity. So = also user identity. Why public Identity, because it was verified by an public (operator) = entity. So the user can be reached by this P-A-ID. So it is the identity of the = user sending the message, but it was included by the network. For what should we use such an asserted identity?=20 Of course presenting the identity to an destination user is one use. And since the Identity is trusted of course it is ideal to write Call = Data Records. For Billing and accounting purposes. If I not use the = P-A-ID what should I use for that? And as far as I know that was also = discussed when the P-A-ID was defined. As far as I know IETF is defining protocol tools that are used in a = generic manner and that are not bind to specific uses. So P-A-ID is used = in such an generic manner for: Originating Identification Presentation, Billing, Call Barring services, = as criteria for allowing services ect. Also in RFC4474 is mentioned: RFC 3325 [12] defines the "id" priv-value token, which is specific to the P-Asserted-Identity header. The sort of assertion provided by the P-Asserted-Identity header is very different from the Identity header presented in this document. It contains additional information about the sender of a message that may go beyond what appears in the From header field; P-Asserted-Identity holds a definitive identity for the sender that is somehow known to a closed network of intermediaries that presumably the network will use this identity for billing or security purposes. ... So it is here also mentioned for what purposes the P-A-ID is used for. = And many people looked over this wording as far as I know. How came this = people to this assumption? >From header in the past was a user provided header and therefore not = useful for billing at least. But back to the issue. The From header is a user provided identity (because put in by the = sending UA) that is also reflecting the identity where the request is = coming from. The user could set every identity in where he is reachable with his = device. So if he has 10 devices at home so he had a couple of addresses = possible. Of course such identities could be also used as public = identities if configures by the asserting entity. But within some = domains(like the IMS) this could lead to more complexity than needed. So = this other identities will be handled as private identities that can be = set by the user and in addition the P-A-ID will be set as a public one. = With all the advantages as mentioned above. Such a behaviour is also used within the PSTN/ISDN for entities called = PBX. With equal principles one asserted identity where you can reach at = least the device sending the initial request. And a private identity = reaching a special extension. This principles were discussed also several times on different IETF = lists. Based on this assumptions the interworking with the PSTN/ISDN was = defined and also services within the IMS. Based on this I was pointing to these facts that should be taken into = consideration within your draft. So at least coping information from a = FROM header into the P-A-ID without looking into the P-A-ID and the = existing trust relationship of the sending domain. Ideally or at least = in many cases the content of the From header would be equal to the = content of the P-A-ID. And of course the P-A-ID can be deleted if = received from a untrusted domain. What I'm assuming that your document should show is a possibility to = generate a P-A-ID in case the calls enter a trusted domain where a the = P-A-ID is needed and not included within the Request and the From is = authenticated due to the rules of RFC4474. And vice versa if possible.=20 Best Regards Roland=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Mittwoch, 18. Oktober 2006 16:28 > An: Jesske, Roland > Cc: sip@ietf.org; Jacobsohn, Dieter; Seibel, Matthias > Betreff: Re:=20 > [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments >=20 >=20 > Well, this harkens back to my rant during the last IETF meeting. My=20 > point was that this usage of both P-A-ID and From you are=20 > describing is=20 > not the semantics implied by RFC 3325 or RFC 3261, but rather a=20 > "decision" by 3gpp, ITU and others to use PAID as a billing identity. >=20 > Indeed I quote RFC 3325: >=20 > 9.1 The P-Asserted-Identity Header >=20 > The P-Asserted-Identity header field is used among trusted SIP > entities (typically intermediaries) to carry the identity=20 > of the user > sending a SIP message as it was verified by authentication. >=20 >=20 > To me, the "identity of the user sending a SIP message" is NOT the=20 > "identity of the entity that will be billed for this=20 > request". It means=20 > as it says - it is the identity of the *user* that *sent* the request. >=20 > Quoting from RFC 3261: >=20 > 8.1.1.3 From >=20 > The From header field indicates the logical identity of=20 > the initiator > of the request, possibly the user's address-of-record. >=20 >=20 > These are identical definitions, the only difference being the term=20 > 'logical', which is implied I think in any system that assigns=20 > identities to users. >=20 > I would like to understand how one can interpret these texts to mean=20 > that P-A-ID is a billing identity while From is the user's identity. >=20 > -Jonathan R. >=20 >=20 > Jesske, R wrote: >=20 > > Dear all, > > With regard to the following section I have some concerns=20 > regarding the > > thought use of the P-Asserted-Identity. > >=20 > > 4.3. Ingress Proxy > >=20 > > .... If the identity > > is verified, the ingress proxy SHOULD insert a=20 > P-Asserted-ID header > > field containing the identity contained in the From=20 > header field of > > the request. The proxy SHOULD NOT remove the Identity=20 > and Identity- > > Info header fields. This allows for SIP networks where there are > > more than two administrative domains in a request path, and also > > allows for a UA to verify the signature on its own if it should > > desire.... > >=20 > > This will violate the use of the From and P-Asserted-Identity header > > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN=20 > including the mapping > > with the PSTN. > >=20 > > The P-Asserted-Identity is used as a public ID that is=20 > trusted. The From > > header is set by the user itself and is untrusted. So that=20 > there is the > > possibility to have two different identities within one INVITE. > > To equalise such identities within a B2BUA at the ingress=20 > even if the > >>From is also a now secure and trusted ID. > >=20 > > Within the NGN this two identities are used for PBX=20 > services to present > > the main PBX number and a individual extension of the PBX. > >=20 > > Also the deletion and re-inclusion is against the rules of=20 > the RFC3325. > > The destination domain is not allowed to change the identity of the > > originating domain. > >=20 > > If such procedures will be done also charging and billing mechanisms > > used between domains will be violated. because the=20 > P-Asserted-Identity > > is the base identity of the origin domain on Billing and charging. > >=20 > > Best Regards > >=20 > > Roland > >=20 >=20 > --=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 Wed Oct 18 14:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGUQ-0003tP-EV; Wed, 18 Oct 2006 14:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGUP-0003tD-0m for sip@ietf.org; Wed, 18 Oct 2006 14:50:05 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGUN-0006O8-Mw for sip@ietf.org; Wed, 18 Oct 2006 14:50:04 -0400 Received: from [64.101.181.232] (dhcp-64-101-181-232.cisco.com [64.101.181.232]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9IHqtgx015861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Oct 2006 12:52:56 -0500 In-Reply-To: <85108216918A984C8C60172D7C84770A56F7AD@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A56F7AD@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57BDDE27-9CC1-45AA-B63E-C33BB9A091FF@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: AW: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments Date: Wed, 18 Oct 2006 13:49:30 -0500 To: "Jesske, R" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, Dieter.Jacobsohn@t-mobile.net, "Seibel, Matthias" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 18, 2006, at 1:03 PM, Jesske, R wrote: > And since the Identity is trusted of course it is ideal to write > Call Data Records. For Billing and accounting purposes. If I not > use the P-A-ID what should I use for that? And as far as I know > that was also discussed when the P-A-ID was defined. I think it is reasonable to base accounting on P-A-ID or other expression of sender identity if that's your business agreement. OTOH, you might also consider "collect calls" and things like that which might effect other business arrangements. All of this is outside the IETF's scope. On the other hand, redefining the usage such that P-A-ID indicates the billing identity instead of sender identity would be a Bad Thing, and it would certainly be within IETF's scope to say so. -- 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 Oct 18 15:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHRa-0002Wm-4J; Wed, 18 Oct 2006 15:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHQS-00011X-16; Wed, 18 Oct 2006 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHQQ-0003my-KY; Wed, 18 Oct 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 94E3326E4B; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001Tk-Do; Wed, 18 Oct 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: Wed, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-session-policy-framework-00.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 : A Framework for Session Initiation Protocol (SIP) Session Policies Author(s) : V. Hilt, et al. Filename : draft-ietf-sip-session-policy-framework-00.txt Pages : 27 Date : 2006-10-18 Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framework-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-policy-framework-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-policy-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-18124925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-policy-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-policy-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18124925.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 Wed Oct 18 17:45:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJBo-0002ce-Rt; Wed, 18 Oct 2006 17:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJBn-0002c5-Oi; Wed, 18 Oct 2006 17:43:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJBl-00087x-QH; Wed, 18 Oct 2006 17:43:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Oct 2006 14:43:01 -0700 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 k9ILh1el004662; Wed, 18 Oct 2006 17:43:01 -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 k9ILh1YJ028785; Wed, 18 Oct 2006 17:43:01 -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, 18 Oct 2006 17:43:01 -0400 Received: from [161.44.55.215] ([161.44.55.215]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 17:43:01 -0400 Message-ID: <45369FE5.8060106@cisco.com> Date: Wed, 18 Oct 2006 17:43:01 -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: IETF SIP List , IETF Sipping List , enum@ietf.org, list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2006 21:43:01.0078 (UTC) FILETIME=[62428760:01C6F2FE] DKIM-Signature: a=rsa-sha1; q=dns; l=1111; t=1161207781; x=1162071781; 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:New=20I-D=20on=20usage=20of=20phone=20numbers=20in=20SIP=20[DO=20NOT=20R EPLY!] |To:IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20enum@ietf.org, =20list=20iptel=20; X=v=3Dcisco.com=3B=20h=3Dx2VOK/URLoBX55duy//nU8RGxVg=3D; b=da0NjqSIGQtGuiwGOXjONOa6aUAwrwZSmZOqSCxt3+Vss4JjLFj4CTOARm5Va36WBUULCSwv Du9ADHrxWyf1Zx1TUlM2QENvD+jUexS0AgOOIjV61V7+3zMeYe5nKs/4; 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Sip] New I-D on usage of phone numbers in SIP [DO NOT REPLY!] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org PLEASE DO NOT REPLY TO THIS POST. My apologies for the cross post. I have submitted the following I-D: http://www.ietf.org/internet-drafts/draft-rosenberg-rai-phone-names-numbers-00.txt I gave it a -rai moniker since it touches on issues central to at least four working groups. If you are interested in discussion this document, please let us do so only on sipping@ietf.org. The document proposes a framework and architecture for the usage of phone numbers with SIP. It tries to answer questions like the difference between a tel URI and SIP URI with user=phone, when to use each, what the meaning of concepts like LNP and freephone are in a pure-SIP world, the architectural role of ENUM, and impacts on PSTN interoperability, and so on. 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 Thu Oct 19 03:54:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSgI-00014B-30; Thu, 19 Oct 2006 03:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSgC-0000w1-JM for sip@ietf.org; Thu, 19 Oct 2006 03:51:04 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSdx-0005vF-RT for sip@ietf.org; Thu, 19 Oct 2006 03:48:47 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9J7mg1t005861; Thu, 19 Oct 2006 02:48:42 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Oct 2006 02:48:42 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Oct 2006 09:48:19 +0200 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] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.txt Date: Thu, 19 Oct 2006 09:48:18 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180625AE3@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.txt Thread-Index: AcbywgLvnZMd1DvBTc23REz4Sc/09AAkIkbA From: "Drage, Keith \(Keith\)" To: "Jonathan Rosenberg" , "Vasudeva M" X-OriginalArrivalTime: 19 Oct 2006 07:48:19.0191 (UTC) FILETIME=[F18AC870:01C6F352] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 More to the point, these documents only create the registries, and populate them with the current information at the time they were published.=20 These registries are updated by the IANA considerations of every SIP extension that is then published, but RFC 3968 and RFC 3969 will never be updated (unless there is a problem with the registry structure itself). Therefore I would suggest that RFC 3968 and RFC 3969 do not carry information to the readership of the hitchhiker's guide. The information that those readers need is the IANA registry itself. Keith =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 18 October 2006 15:29 > To: Vasudeva M > Cc: sip@ietf.org > Subject: Re: [Sip] Re: A Comment=20 > draft-ietf-sip-hitchhikers-guide-00.txt >=20 > Well, as you say, the current scope of the guide is only=20 > extensions, SIP objects, and SDP and extensions targeted=20 > specifically for SIP. Including informational documents makes=20 > this into a massive bloat. I would rather keep the current scope. >=20 > -Jonathan R. >=20 > Vasudeva M wrote: >=20 > > Hi, > >=20 > > Would it be OK if the references (RFC3968 and RFC3969) which lists=20 > > currently IANA registered SIP headers(and URI parameters)=20 > are included=20 > > in hitchhikers' guide ? (even though it does not=20 > extend/modify the SIP > > protocol.) > >=20 > > Regards, > > Vasu > >=20 > >=20 > >=20 > > On 10/18/06, *Jonathan Rosenberg* > > wrote: > >=20 > > THanks for the comments, and apologies for the slow=20 > response. See below. > >=20 > > Samir Srivastava wrote: > >=20 > > > Hi, > > > > > > > > > > > > 1) Shouldn't we have reference to the open bugs in this > > guide in > > > some form. Atleast a reference to bugzilla web site? > >=20 > > That is not within the scope of this document. There is ongoing > > discussion on what to do with those bugs, no conclusion=20 > yet. But this > > document serves only to enumerate the SIP specifications. > >=20 > > > > > > > > > > > > 2) It refers the RFC 2976 for SIP INFO.=20 > Shouldn't it refer > > the RFC > > > 2833 there. We may be widening its scope to media too.. > >=20 > > INFO is an existing normative extension to SIP and so=20 > it is referenced. > > That doesn't mean we are proposing it be used for DTMF;=20 > it just means > > its an extension. RFC 2833 is not a SIP extension, it is an RTP > > extension. So it is not included. > >=20 > >=20 > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow =20 > Parsippany, NJ 07054-2711 > > Cisco Systems > > jdrosen@cisco.com > > =20 > FAX: (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 sip-implementors@cs.columbia.edu > > for questions=20 > on current sip > > Use sipping@ietf.org for new=20 > developments > > on the application of sip > >=20 > >=20 >=20 > --=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=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 Oct 19 04:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTKp-0003iu-JV; Thu, 19 Oct 2006 04:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTKn-0003ik-JV for sip@ietf.org; Thu, 19 Oct 2006 04:33:01 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTKi-00076M-6D for sip@ietf.org; Thu, 19 Oct 2006 04:33:01 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9J8WsuG023787; Thu, 19 Oct 2006 03:32:54 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Oct 2006 03:32:54 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Oct 2006 10:32:16 +0200 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] Recent List of all SIP headers in IANA registry Date: Thu, 19 Oct 2006 10:32:15 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180625B59@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Recent List of all SIP headers in IANA registry Thread-Index: Acbyv1A/2UY4J7JcS++NBq/7CLY3/wAmYnqg From: "Drage, Keith \(Keith\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 19 Oct 2006 08:32:16.0180 (UTC) FILETIME=[154F5F40:01C6F359] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 It also includes those internet-drafts in the RFC editor queue that have completed the IANA step in that publication process. This may be a considerable period in advance of publication. Thus there are IESG approved documents there that are not yet published. Regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 18 October 2006 15:11 > To: Drage, Keith (Keith) > Cc: Vasudeva M; sip@ietf.org > Subject: Re: [Sip] Recent List of all SIP headers in IANA registry >=20 > Note that the registry only reflects those headers defined in RFCs.=20 > Proposals for new headers, appearing in drafts that haven't=20 > yet made RFC, aren't listed anywhere. >=20 > It would be nice if there were some way to have drafts=20 > reflected in the registry, with appropriate indication. But=20 > that would probably be too much work for IANA. >=20 > Paul >=20 > Drage, Keith (Keith) wrote: > > The IANA registry is externally visible: > > =20 > > http://www.iana.org/numbers.html > > =20 > > and search for Session Initiation Protocol (SIP) Parameters > >=20 > > Specifically they are at: > >=20 > > http://www.iana.org/assignments/sip-parameters > >=20 > > The purpose of RFC 3968 and RFC 3969 was to create these=20 > registries so=20 > > IANA could continue to populate them from the IANA considerations=20 > > sections of subsequent published documents (in accordance with the=20 > > rules provided). > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > ________________________________ > >=20 > > From: Vasudeva M [mailto:vasudeva.manjunath@gmail.com]=20 > > Sent: 18 October 2006 10:30 > > To: sip@ietf.org > > Subject: [Sip] Recent List of all SIP headers in IANA registry > > =09 > > =09 > > Hi All, > > =09 > > I wanted to know whether there is ANY Central place to=20 > see currently=20 > > IANA Registered SIP Headers... > > I checked out rfc3968 which gives all the SIP Headers in IANA=20 > > Registry. > > The RFC was itself published in 2004. I could not find=20 > any other=20 > > update to this RFC. > > =09 > > I would like to get the Latest list of all the SIP=20 > Headers in the=20 > > IANA registry and the corresponding RFCs/drafts... > > Any pointers would be really helpful. (google didn't help much > > though...) > > =09 > > Thanks and Best Regards,=20 > > Vasu > > =09 > >=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 sip-implementors@cs.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 Oct 19 10:25:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYmY-0003Yb-Mx; Thu, 19 Oct 2006 10:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYmX-0003SZ-2A for sip@ietf.org; Thu, 19 Oct 2006 10:22:01 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYmG-0006fu-G9 for sip@ietf.org; Thu, 19 Oct 2006 10:22:01 -0400 Received: from [10.10.16.121] (guestnat-69.mdacc.tmc.edu [143.111.239.69]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9JDOoY0021673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Oct 2006 08:24:50 -0500 In-Reply-To: <5D1A7985295922448D5550C94DE29180625AE3@DEEXC1U01.de.lucent.com> References: <5D1A7985295922448D5550C94DE29180625AE3@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DF1F6AC-F4B4-4587-9B1A-98AFC13966D0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: A Comment draft-ietf-sip-hitchhikers-guide-00.txt Date: Thu, 19 Oct 2006 09:21:26 -0500 To: "Drage, Keith ((Keith))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 The suggestion is not to add RFCs 3968 and 3969 to the Guide as "critical SIP documents", but to put some advisory text that says "Note that in addition to the RFCs, the following IANA registries contain important information about SIP and extensions thereto". That actually sounds fairly reasonable. Scenario: Joebob Smith, college student, is reading the Guide to figure out what else he needs to read to understand SIP. In addition to the RFCs, he needs to be cognizant of the relevant IANA registries. -- Dean On Oct 19, 2006, at 2:48 AM, Drage, Keith ((Keith)) wrote: > More to the point, these documents only create the registries, and > populate them with the current information at the time they were > published. > > These registries are updated by the IANA considerations of every SIP > extension that is then published, but RFC 3968 and RFC 3969 will never > be updated (unless there is a problem with the registry structure > itself). > > Therefore I would suggest that RFC 3968 and RFC 3969 do not carry > information to the readership of the hitchhiker's guide. The > information > that those readers need is the IANA registry itself. > > Keith > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 18 October 2006 15:29 >> To: Vasudeva M >> Cc: sip@ietf.org >> Subject: Re: [Sip] Re: A Comment >> draft-ietf-sip-hitchhikers-guide-00.txt >> >> Well, as you say, the current scope of the guide is only >> extensions, SIP objects, and SDP and extensions targeted >> specifically for SIP. Including informational documents makes >> this into a massive bloat. I would rather keep the current scope. >> >> -Jonathan R. >> >> Vasudeva M wrote: >> >>> Hi, >>> >>> Would it be OK if the references (RFC3968 and RFC3969) which lists >>> currently IANA registered SIP headers(and URI parameters) >> are included >>> in hitchhikers' guide ? (even though it does not >> extend/modify the SIP >>> protocol.) >>> >>> Regards, >>> Vasu >>> >>> >>> >>> On 10/18/06, *Jonathan Rosenberg* >> > wrote: >>> >>> THanks for the comments, and apologies for the slow >> response. See below. >>> >>> Samir Srivastava wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> 1) Shouldn't we have reference to the open bugs in this >>> guide in >>>> some form. Atleast a reference to bugzilla web site? >>> >>> That is not within the scope of this document. There is ongoing >>> discussion on what to do with those bugs, no conclusion >> yet. But this >>> document serves only to enumerate the SIP specifications. >>> >>>> >>>> >>>> >>>> 2) It refers the RFC 2976 for SIP INFO. >> Shouldn't it refer >>> the RFC >>>> 2833 there. We may be widening its scope to media too.. >>> >>> INFO is an existing normative extension to SIP and so >> it is referenced. >>> That doesn't mean we are proposing it be used for DTMF; >> it just means >>> its an extension. RFC 2833 is not a SIP extension, it is an RTP >>> extension. So it is not included. >>> >>> >>> -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 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 19 15:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadUj-0005TA-4O; Thu, 19 Oct 2006 15:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadUe-0005Na-6P; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadUc-0003xD-RP; Thu, 19 Oct 2006 15:23:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2006 12:23:51 -0700 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 k9JJNotj004329; Thu, 19 Oct 2006 15:23:50 -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 k9JJNlYP028366; Thu, 19 Oct 2006 15:23:50 -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); Thu, 19 Oct 2006 15:23:49 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:23:48 -0400 Message-ID: <4537D0C4.5020105@cisco.com> Date: Thu, 19 Oct 2006 15:23:48 -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: avt@ietf.org, ecrit@ietf.org, enum@ietf.org, geopriv@ietf.org, ieprep@ietf.org, iptel@ietf.org, mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, sip@ietf.org, sipping@ietf.org, speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:23:48.0914 (UTC) FILETIME=[1A653120:01C6F3B4] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161285830; x=1162149830; 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:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:avt@ietf.org, =20ecrit@ietf.org, =20enum@ietf.org, =20geopriv@ietf.org, =0A= 20=20=20=20=20=20=20=20ieprep@ietf.org, =20iptel@ietf.org, =20mmusic@ietf.org , =20sigtran@ietf.org, =0A=20=20=20=20=20=20=20=20simple@ietf.org, =20sip@ietf .org, =20sipping@ietf.org, =20speechsc@ietf.org, =0A=20=20=20=20=20=20=20=20sp eermint@ietf.org,=20xcon@ietf.org; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=KrOzK3fR06ATri/gT7YJZroJcol7TSpMYe5BZE33gFcC/1PSyZC+oxmWK+oIC+fJQIbVoFL+ nf48uscnxvpV77HTZ0nnFeZmJMX4MuuOimxi0aG7+C8ixmvrHWsG0fmT; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.2 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Sip] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Oct 19 15:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadeM-0001G2-JT; Thu, 19 Oct 2006 15:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadeK-0001BV-8G for sip@ietf.org; Thu, 19 Oct 2006 15:33:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadeI-0005bS-Un for sip@ietf.org; Thu, 19 Oct 2006 15:33:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2006 15:33:51 -0400 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 k9JJXoHi000399 for ; Thu, 19 Oct 2006 15:33:50 -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 k9JJXdDg007716 for ; Thu, 19 Oct 2006 15:33:50 -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, 19 Oct 2006 15:33:41 -0400 Received: from [161.44.55.227] ([161.44.55.227]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 15:33:41 -0400 Message-ID: <4537D315.4090009@cisco.com> Date: Thu, 19 Oct 2006 15:33:41 -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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 19:33:41.0045 (UTC) FILETIME=[7B553650:01C6F3B5] DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1161286430; x=1162150430; 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:ICE=20Tutorial=20during=20IETF=2067!=20[DO=20NOT=20REPLY] |To:IETF=20SIP=20List=20; X=v=3Dcisco.com=3B=20h=3DIVH9amnYVaV4pfzKKjl/WmQt0Lg=3D; b=elgV+vYRFHEnpcuCx+AOSiwdNMPty8x+cqFQ9u+EjG3gcUwVVUWA8MxwdZokfECol9rJpkfP QEBtP8fBBPRU2axwH5tcBa7ZYR5vQGEg/px2xOR/WSCiBMvmrTHZGzB+; 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: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] ICE Tutorial during IETF 67! [DO NOT REPLY] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt) WHEN: Tuesday, November 7 1130-1300 (lunch logistics are in progress and will be announced ASAP) WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- 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 Oct 19 15:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadfF-0001jr-EW; Thu, 19 Oct 2006 15:34:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GadfD-0001hl-5g for sip@ietf.org; Thu, 19 Oct 2006 15:34:47 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GadfB-0005lY-OS for sip@ietf.org; Thu, 19 Oct 2006 15:34:47 -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 k9JJYgl28470; Thu, 19 Oct 2006 15:34: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] identity-coexistence: the value of signatures Date: Thu, 19 Oct 2006 14:34:41 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F208147@zrc2hxm2.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22141200@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] identity-coexistence: the value of signatures Thread-Index: AcbxkKbpwOIDwe9STf2uGpxn0cHefgAX46hgAHE8rvA= From: "Samir Srivastava" To: "Henry Sinnreich" , "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 You don't trust Proxies for the identity etc, but for cipher-suites, encryption etc group argued that we need to trust the proxies without any verification. Thx Samir > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, October 17, 2006 6:32 AM > To: Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] identity-coexistence: the value of signatures >=20 > This is an excellent protocol centric argument about not trusting > intermediaries for identity and security. Not to mention what evil > intermediaries or compromised intermediaries can do. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, October 16, 2006 9:03 PM > To: IETF SIP List > Subject: [Sip] identity-coexistence: the value of signatures >=20 > I have on my long list of drafts to revise before the deadline, the > identity-coexistence draft: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexist > ence-00.txt >=20 > There was a good thread back in August on this topic, driven off on some >=20 > comments by Cullen. Here is the thread URL if you are interested: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg14996.html >=20 > There were a few issues in this thread, but the biggest byfar is the > issue of what to do in transit domains that have b2bua which modify the > Contact or SDP, invalidating the signature. Consider, for example, a > chain of domains A->B->C->D. The caller is in A.com and the called party >=20 > in B.com. The From header field of sip:caller@A.com is signed by a proxy >=20 > in A.com. It goes through two transit providers B and C prior to > reaching D. If a b2bua in B or C are B2bUA the signature is invalidated. >=20 > One proposal, that I think Cullen was arguing for unless I am mistaken, > was that if B modifies the message it resigns using its own cert. C > receives this, and if it trusts B it would resign with its cert too. > Then it arrives at D, who of course trusts A and so resigns it with its > own cert. THen, the idea is that teh UAS is configured to accept a > signature even if the domain in the cert doesn't match the From domain, > if the cert is from a configured list of good domains, which typically > is just one domain - its own, D.com. >=20 > Hadriel posted in reply that if you do this, why bother with SIP > identity? May as well use P-Asserted-ID since you are back to transitive >=20 > trust. And indeed I have to agree with this. The reason I felt that SIP > identity is superior to P-Asserted-ID is that I, in the terminating > domina, know exactly who the originating domain was, and I could use > that information to plug it into black/white lists, authorization rules, >=20 > and so on, to decide whether to accept the call. >=20 > The canonical use case I have for this is a call from spammers.com, who > gets service from their provider littlecountry.com, who gets service > from biginterconnectprovider.com, which connects to my own provider, > myprovider.com. Though there IS in fact transitive trust at each hop, > the net value of P-Asserted-ID is nil here. The reason is that the value >=20 > of P-Asserted-ID is equal to the trustworthiness of the LEAST > trustworthy provider in the chain. In a transit situation, this > exponentially approaches zero. However with SIP identity, I can directly >=20 > determine that this is coming from spammers.com and look them up in > sipspamhaus.org and reject their calls as a matter of local policy. >=20 > So if you emloy resigning at each transit hop, you will basically > eliminate all of the benefit that SIP identity brings to the table, and > I think thats bad. >=20 > Consequently, unless the transit is something like an anonymizing > provider (and there are legitimate use cases for it), which purposefully >=20 > masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK > THROUGH TRANSIT B2BUA*. That is the cost of the increased security we > get. >=20 > 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 >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 19 18:53:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gagiq-0002wL-5u; Thu, 19 Oct 2006 18:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gagif-0002h1-Aa; Thu, 19 Oct 2006 18:50:33 -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 1Gagif-00031Q-8C; Thu, 19 Oct 2006 18:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gagie-0003fV-Ub; Thu, 19 Oct 2006 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A4BDC175A5; Thu, 19 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GagiA-00079M-82; Thu, 19 Oct 2006 18: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, 19 Oct 2006 18: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-05.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-05.txt Pages : 26 Date : 2006-10-19 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-05.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-05.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-05.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-10-19151903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-location-conveyance-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-location-conveyance-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19151903.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 Oct 19 18:53:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GagiH-0002YL-Dd; Thu, 19 Oct 2006 18:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GagiB-0002WC-RO; Thu, 19 Oct 2006 18:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GagiA-0002x0-FK; Thu, 19 Oct 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6C17F26E21; Thu, 19 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GagiA-00079U-A7; Thu, 19 Oct 2006 18: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, 19 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-07.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-07.txt Pages : 20 Date : 2006-10-19 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 ensure 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. For TLS transports, this will frequently cause a pair of SIP entities to use one connection for requests sent in each direction, resulting in potential scaling and performance problems. This document proposes that a TLS connection, once opened, can be used to send requests in either direction. Unfortunately, TCP connections cannot be shared in the same manner due to the risk of service hijacking. This document proposes an alternate way to perform TCP connection reuse. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-07.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-07.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-07.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-10-19155151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-connect-reuse-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-connect-reuse-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19155151.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 Oct 19 20:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahyG-0003k6-NF; Thu, 19 Oct 2006 20:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahyF-0003ji-J8 for sip@ietf.org; Thu, 19 Oct 2006 20:10:43 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GahyA-00071e-TD for sip@ietf.org; Thu, 19 Oct 2006 20:10:43 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Oct 2006 17:10:16 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9K07evV000020; Thu, 19 Oct 2006 17:07:45 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9K09rPP027528; Thu, 19 Oct 2006 17:10:06 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 17:09:57 -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] identity-coexistence: the value of signatures Date: Thu, 19 Oct 2006 17:09:55 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141233@namail5.corp.adobe.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F208147@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] identity-coexistence: the value of signatures Thread-Index: AcbxkKbpwOIDwe9STf2uGpxn0cHefgAX46hgAHE8rvAACXvvQA== From: "Henry Sinnreich" To: "Samir Srivastava" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 20 Oct 2006 00:09:57.0117 (UTC) FILETIME=[137112D0:01C6F3DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 > You don't trust Proxies for the identity etc, That's right; you don't trust them for anything, especially when your fortune or life is at stake. Thanks, Henry -----Original Message----- From: Samir Srivastava [mailto:samirsr@nortel.com]=20 Sent: Thursday, October 19, 2006 2:35 PM To: Henry Sinnreich; Jonathan Rosenberg; IETF SIP List Subject: RE: [Sip] identity-coexistence: the value of signatures You don't trust Proxies for the identity etc, but for cipher-suites, encryption etc group argued that we need to trust the proxies without any verification. Thx Samir > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, October 17, 2006 6:32 AM > To: Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] identity-coexistence: the value of signatures >=20 > This is an excellent protocol centric argument about not trusting > intermediaries for identity and security. Not to mention what evil > intermediaries or compromised intermediaries can do. >=20 > Thanks, Henry >=20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, October 16, 2006 9:03 PM > To: IETF SIP List > Subject: [Sip] identity-coexistence: the value of signatures >=20 > I have on my long list of drafts to revise before the deadline, the > identity-coexistence draft: >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexist > ence-00.txt >=20 > There was a good thread back in August on this topic, driven off on some >=20 > comments by Cullen. Here is the thread URL if you are interested: >=20 > http://www1.ietf.org/mail-archive/web/sip/current/msg14996.html >=20 > There were a few issues in this thread, but the biggest byfar is the > issue of what to do in transit domains that have b2bua which modify the > Contact or SDP, invalidating the signature. Consider, for example, a > chain of domains A->B->C->D. The caller is in A.com and the called party >=20 > in B.com. The From header field of sip:caller@A.com is signed by a proxy >=20 > in A.com. It goes through two transit providers B and C prior to > reaching D. If a b2bua in B or C are B2bUA the signature is invalidated. >=20 > One proposal, that I think Cullen was arguing for unless I am mistaken, > was that if B modifies the message it resigns using its own cert. C > receives this, and if it trusts B it would resign with its cert too. > Then it arrives at D, who of course trusts A and so resigns it with its > own cert. THen, the idea is that teh UAS is configured to accept a > signature even if the domain in the cert doesn't match the From domain, > if the cert is from a configured list of good domains, which typically > is just one domain - its own, D.com. >=20 > Hadriel posted in reply that if you do this, why bother with SIP > identity? May as well use P-Asserted-ID since you are back to transitive >=20 > trust. And indeed I have to agree with this. The reason I felt that SIP > identity is superior to P-Asserted-ID is that I, in the terminating > domina, know exactly who the originating domain was, and I could use > that information to plug it into black/white lists, authorization rules, >=20 > and so on, to decide whether to accept the call. >=20 > The canonical use case I have for this is a call from spammers.com, who > gets service from their provider littlecountry.com, who gets service > from biginterconnectprovider.com, which connects to my own provider, > myprovider.com. Though there IS in fact transitive trust at each hop, > the net value of P-Asserted-ID is nil here. The reason is that the value >=20 > of P-Asserted-ID is equal to the trustworthiness of the LEAST > trustworthy provider in the chain. In a transit situation, this > exponentially approaches zero. However with SIP identity, I can directly >=20 > determine that this is coming from spammers.com and look them up in > sipspamhaus.org and reject their calls as a matter of local policy. >=20 > So if you emloy resigning at each transit hop, you will basically > eliminate all of the benefit that SIP identity brings to the table, and > I think thats bad. >=20 > Consequently, unless the transit is something like an anonymizing > provider (and there are legitimate use cases for it), which purposefully >=20 > masks identity and resigns, then *SIP IDENTITY DOES NOT AND CANNOT WORK > THROUGH TRANSIT B2BUA*. That is the cost of the increased security we > get. >=20 > 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 >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 19 20:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiMI-0003OP-I7; Thu, 19 Oct 2006 20:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiMG-0003MW-Na; Thu, 19 Oct 2006 20:35:32 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaiMF-000327-7H; Thu, 19 Oct 2006 20:35:32 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Oct 2006 17:35:26 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9K0WwvV004528; Thu, 19 Oct 2006 17:32:58 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9K0YoeC005766; Thu, 19 Oct 2006 17:35:08 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 17:35:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Oct 2006 17:34:06 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141235@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reflections on Internet Transparency Thread-Index: Acbz3uEgekvUKJbHQ8Co6JzPaCd39Q== From: "Henry Sinnreich" To: , , X-OriginalArrivalTime: 20 Oct 2006 00:35:05.0415 (UTC) FILETIME=[96751570:01C6F3DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: elwynd@dial.pipex.com, bernarda@microsoft.com Subject: [Sip] Reflections on Internet Transparency X-BeenThere: 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="===============1232841506==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1232841506== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F3DF.95BCAA18" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F3DF.95BCAA18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My apology for posting this note about the AIB document on all three lists, but it seems all three WGs (and other as well) must request their contributors to specify in a _new section_ stating to what extent their I-Ds take into account the Internet e2e principle: =20 http://www.ietf.org/internet-drafts/draft-iab-net-transparent-00.txt=20 =20 It seems too many I-Ds in these WG are disregarding Internet Transparency as it applies to application, to QoS, to DNS usage and other. =20 Such a note is as important as the sections on Security and IANA IMHO, since it affects the very survival of the Internet. =20 Thanks, Henry ------_=_NextPart_001_01C6F3DF.95BCAA18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My apology for posting this note about the AIB document on all = three lists, but it seems all three WGs (and other as well) must request their contributors to specify in a _new = section_ stating to what extent their I-Ds take into account the Internet e2e = principle:

 

http://www.ietf.org/internet-drafts/draft-iab-net-transparent-00.txt=

 

It seems too many I-Ds in these = WG are disregarding Internet Transparency as it applies to application, to QoS, = to DNS usage and other.

 

Such a note is as important as = the sections on Security and IANA IMHO, since it affects the very survival = of the Internet.

 

Thanks, = Henry

------_=_NextPart_001_01C6F3DF.95BCAA18-- --===============1232841506== 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 --===============1232841506==-- From sip-bounces@ietf.org Fri Oct 20 02:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GantQ-00032l-EX; Fri, 20 Oct 2006 02:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GantP-00032P-GT for sip@ietf.org; Fri, 20 Oct 2006 02:30:07 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GantN-0007UQ-W5 for sip@ietf.org; Fri, 20 Oct 2006 02:30:07 -0400 Received: (qmail 29341 invoked by uid 0); 20 Oct 2006 06:31:14 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 20 Oct 2006 06:31:14 -0000 Message-ID: <004b01c6f411$2b1585d0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt Date: Fri, 20 Oct 2006 08:29: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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: geopriv@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 this draft has much improved. However, there remains an issue with the ABNF: Geolocation = "Geolocation" HCOLON (locationURI *(COMMA locationURI)) locationURI = sip-URI / sips-URI / pres-URI / cid-URI / absoluteURI cidURI = "cid:" content-id content-id = addr-spec ; URL encoding of RFC3261 addr-spec I would suggest to use '<' '>' around the URI, and allow for generic header parameters. This is inline with the second example used in section 4.2: Geolocation = "Geolocation" HCOLON (locationValue *(COMMA locationValue))locationValue = LAQUOT locationURI RAQUOT *(SEMI generic-param)locationURI = sip-URI / sips-URI / pres-URI / cid-URI / absoluteURI cidURI = "cid:" content-id content-id = addr-spec ; URL encoding of RFC3261 addr-spec Second comment: section 3.5 still contains the phrase "Appearance of the option tag in the Require header is a request for location to be conveyed." Such semantics are not common for Require Regards, Jeroen Internet-Drafts@ietf.org wrote: >> 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-05.txt >> Pages : 26 >> Date : 2006-10-19 >> >> 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-05.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-05.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-05.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 20 02:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gao12-0006Qg-Oc; Fri, 20 Oct 2006 02:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gao11-0006Ok-1P for sip@ietf.org; Fri, 20 Oct 2006 02:37:59 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gao0z-0000z3-HR for sip@ietf.org; Fri, 20 Oct 2006 02:37:59 -0400 Received: (qmail 3759 invoked by uid 0); 20 Oct 2006 06:37: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 < >; 20 Oct 2006 06:37:42 -0000 Message-ID: <005601c6f412$442d0e70$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: References: Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt Date: Fri, 20 Oct 2006 08:37:51 +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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: geopriv@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 "The entities receiving location MUST obey the privacy and security rules in the PIDF-LO as described in RFC4119, regarding retransmission and retention." Does this mean that a SIP proxy receiving a request with a Geolocation must first inspect the location object before forwarding? For location-by-reference, this may introduce an unacceptable delay, especially when the proxy does not do anything with the location information itself. Proxies that don't understand Geolocation will forward as usual, possibly violating the forwarding policy. You may want to spend some words on this. For proxies that do understand, you could consider inserting a flag in a SIP Geolocation header for the by-reference case, such that a dereference is not needed to obtain the policy Regards, Jeroen Internet-Drafts@ietf.org wrote: >> 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-05.txt >> Pages : 26 >> Date : 2006-10-19 >> >> 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-05.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-05.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-05.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 20 02:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoDo-00008n-EM; Fri, 20 Oct 2006 02:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoDe-0008QN-Cg; Fri, 20 Oct 2006 02: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 1GaoDe-0004gY-66; Fri, 20 Oct 2006 02:51:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaoDd-0007aE-Sl; Fri, 20 Oct 2006 02:51:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D936A2ACCD; Fri, 20 Oct 2006 06:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaoCf-0004fb-JI; Fri, 20 Oct 2006 02: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: Fri, 20 Oct 2006 02:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-hitchhikers-guide-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 : A Hitchhikers Guide to the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-hitchhikers-guide-01.txt Pages : 30 Date : 2006-10-19 The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. Don't Panic! This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-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-hitchhikers-guide-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-hitchhikers-guide-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-10-19200930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-hitchhikers-guide-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-hitchhikers-guide-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-19200930.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 Fri Oct 20 12:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxKg-0004Ci-HV; Fri, 20 Oct 2006 12:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaxKf-0004Bp-1i for sip@ietf.org; Fri, 20 Oct 2006 12:34:53 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaxKd-0005rw-6y for sip@ietf.org; Fri, 20 Oct 2006 12:34:53 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9KFc8NG032650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Oct 2006 10:38:09 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP List Message-Id: From: Dean Willis Date: Fri, 20 Oct 2006 11:34:41 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: ce33913643759a19ac4c14fdbab27ca9 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Draft agenda for IETF 67 X-BeenThere: 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="===============1191295858==" Errors-To: sip-bounces@ietf.org --===============1191295858== Content-Type: multipart/alternative; boundary=Apple-Mail-1-518771272 --Apple-Mail-1-518771272 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've posted a draft agenda for SIP at IETF 67 on the softarmor site: http://www.softarmor.com/sipwg/meets/ietf67/agenda.html I don't like the agenda much, as it seem too crowded. Please make suggestions. Text follows: Draft Agenda, SIP at IETF 67 Session 1: Thursday 1300-1500 Grand Ballroom C Time Topic Discussion leaders Reading List 1300 Agenda Bash and Status Chairs this document 1305 GRUU and Supporting Drafts Jonathan Rosenberg draft-ietf-sip-gruu-11 draft-rosenberg-sip-ua-loose-route-00 1355 Location Conveyance James Polk Brian Rosen draft-ietf-sip-location-conveyance-05 1415 Connected Identity John Elwell draft-ietf-sip-connected-identity-02 1445 Identity Coexistence Jonathan Rosenberg draft-rosenberg-sip-identity-coexistence-01 Session 2: Friday 0900-1130 Grand Ballroom C Time Topic Discussion leaders Reading List 0900 Agenda Bash Chairs This Document 0905 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-05 0935 Outbound Discovery and Mid-Dialog requests Jonathan Rosenberg draft-rosenberg-sip-outbound-discovery-mid-dialog-00 0955 Domain Certs and Connection Reuse Vijay Gurbani draft-gurbani-sip-domain-certs-03 draft-ietf-sip-connect-reuse-07 1030 Diagnostic Responses Scott Lawrence Vijay Gurbani draft-ietf-sip-hop-limit-diagnostics-04 draft-gurbani-sip-large-udp-response-00 1055 UA Profile Delivery Dan Petrie draft-ietf-sip-xcap-config-00 1115 Jonathan Rosenberg Route Constuction draft-rosenberg-sip-route-construct-02 In Case Of Miracle Gonzalo Camarillo Consent draft-ietf-sip-consent-framework-00 draft-ietf-sip-uri-list-conferencing-00 draft-ietf-sip-multiple-refer-00 draft-ietf-sip-uri-list-message-00 draft-ietf-sip-uri-list-subscribe-00 --Apple-Mail-1-518771272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I've posted a draft agenda = for SIP at IETF 67 on the softarmor site:

I don't like the agenda = much, as it seem too crowded. Please make suggestions.

Text follows:

Draft Agenda, SIP at IETF 67



Session 1: Thursday 1300-1500 Grand Ballroom = C


<= /TR><= /TR>
Time
Topic
Discussion leaders
Reading = List
1300
Agenda Bash and Status
Chairs
this = document
1305
GRUU and Supporting Drafts
Jonathan = Rosenberg
1355
Location = Conveyance
James Polk
Brian = Rosen
1415
Connected = Identity
John Elwell
1445
Identity = Coexistence
Jonathan Rosenberg
=


Session 2: = Friday 0900-1130 Grand Ballroom C


0935
= =
Time
Topic
Discussion leaders
Reading = List
0900
Agenda Bash
Chairs
This Document
0905
Outbound
Rohan Mahy
Cullen Jennings
Outbound Discovery=A0
and Mid-Dialog = requests
Jonathan Rosenberg
0955
Domain Certs and=A0
Connection Reuse
Vijay Gurbani
1030
Diagnostic = Responses
Scott Lawrence
Vijay = Gurbani
draft-gurbani-sip-large-udp-response-00
1055
UA Profile = Delivery
Dan Petrie
1115
Jonathan = Rosenberg
Route Constuction
In
Case
Of
Miracle
Gonzalo Camarillo
Consent
<= DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">draft-ietf-sip-multiple-refer-00=A0


= --Apple-Mail-1-518771272-- --===============1191295858== 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 --===============1191295858==-- From sip-bounces@ietf.org Fri Oct 20 13:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayIB-0005tm-L7; Fri, 20 Oct 2006 13:36:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GayI9-0005tf-Nm for sip@ietf.org; Fri, 20 Oct 2006 13:36:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GayI8-00026K-FB for sip@ietf.org; Fri, 20 Oct 2006 13:36:21 -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 k9KHaG607761; Fri, 20 Oct 2006 13:36:16 -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] identity-coexistence: the value of signatures Date: Fri, 20 Oct 2006 12:36:13 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F26A330@zrc2hxm2.corp.nortel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22141233@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] identity-coexistence: the value of signatures Thread-Index: AcbxkKbpwOIDwe9STf2uGpxn0cHefgAX46hgAHE8rvAACXvvQAAkdg4Q From: "Samir Srivastava" To: "Henry Sinnreich" , "Jonathan Rosenberg" , "IETF SIP List" 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 That was my thought too. In encryption etc, with less/no encryption my life is in danger too.=20 Imagine CEO of Company A is talking to CEO of Company X, with call pattern tracking etc, CEO of Company B (which is Competitor of A) comes to know about the talk between A and X and then CEO of B comes to X and clinches the deal. Size of damage varies as per the size of Companies...... This is the potential damage from the Call Pattern Tracking.. I am in danger too for my customers.. This is apart from URI learning etc for the SPAMMERS, which I kept arguing endlessly on the list... Thx Samir=20 > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, October 19, 2006 5:10 PM > To: Srivastava, Samir (SC100:8826); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] identity-coexistence: the value of signatures >=20 > > You don't trust Proxies for the identity etc, >=20 > That's right; you don't trust them for anything, especially when your > fortune or life is at stake. >=20 > Thanks, Henry >=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 akstcbsvmnsdgs@bsv.com Fri Oct 20 15:25:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb00F-0005tJ-Id for sip-archive@lists.ietf.org; Fri, 20 Oct 2006 15:25:59 -0400 Received: from 240.red-81-34-178.dynamicip.rima-tde.net ([81.34.178.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gb00B-0004vP-11 for sip-archive@lists.ietf.org; Fri, 20 Oct 2006 15:25:59 -0400 Received: from 216.240.32.164 (HELO mx0.idiom.com) by lists.ietf.org with esmtp (AKH2GQW515C NKMJ) id E6D2T1-085ICN-WK for sip-archive@lists.ietf.org; Fri, 20 Nov 2006 19:25:54 -0060 Date: Fri, 20 Nov 2006 19:25:54 -0060 From: "Wilma Schmitz" X-Mailer: The Bat! (v3.80.03) Personal X-Priority: 3 (Normal) Message-ID: <083905919.97757507355686@thebat.net> To: sip-archive@lists.ietf.org Subject: climbing every day 27% MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.1 (++++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi Inez, look at it its' 27% UP! I mentioned about this company yesterday known as American Unity Investments Inc (AUNI) Yay, I told you to watch it yesterday and it boomed from .7to .9! I made easy 20% just in one single day.I am amazed, did you buy some as well I hope? As you can see its climbing, but by just looking at it I can tell it's gonna explode even more.So you still have a window to digg in while it's still in it's low.So what a hey, go ahead buy some, make some money while it's there. It can easily do another 30% tomorrow.I wouldn't wait any longer if I be you... I hope it was a helper.I'll email you later this week. Deborah. delicacy may lead you to dissemble; my attentions have been too marked=20= to be mistaken. almost as attended to her conversation with others. his doing so drew her notice.=20= it was at sir william lucas's, From sip-bounces@ietf.org Sat Oct 21 09:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGZE-0005RC-V0; Sat, 21 Oct 2006 09:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbGZC-0005R3-Ua for sip@ietf.org; Sat, 21 Oct 2006 09:07:10 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbGZB-0002sz-JR for sip@ietf.org; Sat, 21 Oct 2006 09:07:10 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9LD79wO002977 for ; Sat, 21 Oct 2006 08:07:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Oct 2006 08:07:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 21 Oct 2006 15:07:07 +0200 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-location-conveyance-05.txt Date: Sat, 21 Oct 2006 15:07:07 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918065E10C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt Thread-Index: Acbz0WPrAB4y2RZ6R363IfNp+KL8HwBM+XMA From: "Drage, Keith \(Keith\)" To: X-OriginalArrivalTime: 21 Oct 2006 13:07:07.0460 (UTC) FILETIME=[CFB48040:01C6F511] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) While this version attempts to incorporate the comments so far, we could have done with a fair amount more discussion for the preparation of this version. I asked the author's to produce it to establish to the WG the current status. We need to get this one finished. After those in current WGLC this one probably has the highest priority for getting out of the door. We are looking for WGLC pretty soon after the next IETF - but we have to get the technical contents there first! Please devote some time to reading it and making comments on the list. The authors have asked for agenda time at IETF#67 and I don't want the discussion there to be just a set of status slides. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 19 October 2006 23:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > Title : Session Initiation Protocol Location=20 > Conveyance > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sip-location-conveyance-05.txt > Pages : 26 > Date : 2006-10-19 > =09 > This document defines an extension to the Session Initiation=20 > Protocol (SIP) to convey geographic location information from one=20 > SIP entity to another SIP entity. The extension covers end to end=20 > conveyance as well as location-based routing, where proxy servers=20 > make routing decisions based on the location of the UAC. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-location-co > nveyance-05.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-sip-location-conveyance-05.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE=20 > /internet-drafts/draft-ietf-sip-location-conveyance-05.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=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 Sat Oct 21 10:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbIBV-0004ua-8U; Sat, 21 Oct 2006 10:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbIBT-0004uV-8p for sip@ietf.org; Sat, 21 Oct 2006 10:50:47 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbIBS-00050I-TY for sip@ietf.org; Sat, 21 Oct 2006 10:50:47 -0400 Received: from [127.0.0.1] (stdhcp-238.va.neustar.com [10.31.13.238]) by ns1.neustar.com (Postfix) with ESMTP id 978A126E32 for ; Sat, 21 Oct 2006 14:50:46 +0000 (GMT) Message-ID: <453A33BB.5010804@neustar.biz> Date: Sat, 21 Oct 2006 07:50:35 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] SIP SAML: Issue #9 - Passing SAML Assertions Per Value References: <45323D98.3050300@gmx.net> <4533F3BA.6000709@ntt-at.com> In-Reply-To: <4533F3BA.6000709@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Shida wrote: > > I have been evaluating the current SIP-SAML profile and for any > information that may be used by intermediaries for routing purposes, > it may be better to include the SAML assertion by value. sure, if there's info in the SAML assertion needed by some entity for some decision, it'll be more efficient overall to have it (the SAML assertion) conveyed directly in the SIP message by value rather than by reference. > SAML [assertion] can > be included in the message body, but that would require UAC to be > SAML aware which might not be a reasonable as it adds a lot of load > to UAC to support SAML, well, maybe or maybe not, it depends. There are shipping cellphones today (eg from Nokia) that support Liberty ID-WSF (full-on XML-based web services stack with SAML-based security features), so it's certainly not impossible for physically small battery-powered devices to support "complex" XML-based protocols and objects. And it's possible for developers in the mobile device biz to write the necessary code. There are likely some scenarios where it makes sense for a UAC to directly obtain SAML assertion(s) attesting to the user's identity and/or other aspects of the user and/or UAC or whatever. > thus to reduce the complexity, adding it to > the SIP header may be a reasonable approach.(Despite the message > size implosion etc., I do think there is some benefits, as have been > discussed on GEOPRIV on a similar context for location information). Rather than just complexity, its perhaps driven more by deployment scenarios to have the UAS being responsible for incorporating security attestation and assurance to a SIP request, as described in RFC4474, which the present draft-ietf-sip-saml-00 "composes" with. I'm taking what you said directly above, "...adding it to the sip header..." to be referring to having intermediaries do so, eg a UAS. > But before I go on, trait-authz requirement with MUST strength > says that the solution MUST provide a way to prevent unauthorized > parties from viewing the contents, which would not hold true if we > include the SAML assertion in the header. Not necessarily, there are ways to address such a requirement. Tho worrying about confidentiality at this point is putting the cart before the horse it seems to me (see next item) > I personally think that the justification for the inclusion of the SAML > assertion in the header really depends on what values will be carried in > SAML assertion. I respectfully disagree, in that there is a higher-level SIP protocol architectural justification/question that needs to be addressed first, and that is: Is it legit from a SIP protocol architectural perspective to specify SIP extensions (eg new SIP protocol header fields) that may, or are expected to, contain data objects of nearly arbitary size (eg O(100s) to O(1000s) octets) and arbitrary complexity? aka BLOBs (Binary Large OBjects) I have been informed verbally by some that specifying a general-purpose approach for accommodating conveyance of such BLOBs (whether or not they are actually conveyed in a "binary" or "textual" encoding let's just call the BLOBs for the purposes of discussion) would be a violation of the "SIP protocol architecture" (due to "..recasting bodies as headers..") and would likely lead over time to just conveying everything in header fields, and thus it won't ever get consensus or be codified. The most concise public example of this argument I can find is this message on this list from this last summer.. RE: [Sip] Location header From: "Peterson, Jon" http://www1.ietf.org/mail-archive/web/sip/current/msg15362.html Alternatively, there are apparently some (including yourself, shida) who feel that conveying-BLOBs-in-SIP-header-fields is not necessarily a violation of the "SIP protocol architecture". The most concise public example of this I've found is this message in response to the above cited one.. Re: [Sip] Location header From: Henning Schulzrinne http://www1.ietf.org/mail-archive/web/sip/current/msg15363.html As far as I can tell from perusal of the SIP mailing list, this discussion isn't convincingly decided one way or another at this point. If it is, then the chairs should make it clear because apparently not everyone realizes it. Plus, there are some gnarly security aspects of including certain types of information "by-value", as you note in your message (portions above), and which the "retargeting" SIP feature especially highlights (see draft-peterson-sipping-retarget-00 (expired)). So it needs to be done carefully. > If not current SIP-profile > should be used to make sure further authentication of the party requesting > the SAML can be provided to make sure the assertion is not given to an > unwanted parties. Just to be clear, I'm assuming you meant "SIP SAML profile spec" when you wrote "SIP-profile". And this brings up a set of points about the general topic of having a relying party retrieving various objects "by reference" from other party(ies). We've acquired some experience with this in actual deployments in the SAML world courtesy the SAML "Browser artifact profile". We often refer to the operation of dereferencing the reference as a "callback". There's a whole range of operational and application implementation issues that can come up with callbacks, detailed below. Given these issues, it seems we should think carefully before obviating any conveyance of BLOBs in SIP header fields "by-value", unless it's already decided and I missed it. =JeffH ------ Application Implementation and Deployment Operational Issues with Callbacks (courtesy Scott Cantor) - firewalls Operationally, it can be a hassle for many deployers to deal with their networking staff, or they are forced into ugly and exotic proxying and port forwarding that makes deployment harder or impossible when TLS is required. - state mgmt Callbacks often introduce statefulness. Statefulness is a scaling problem in high end systems, and makes clustering an implementation much harder. Stateless software can be horizontally scaled very cheaply without single points of failure. The worst kind of callback is the SAML kind, a one-time artifact. That requires instant replication, which isn't practical in WAN clusters, which is why SAML artifacts include an endpoint index. - authentication / configuration Most callback designs require authentication of at least the server, and sometimes the client. Configuring TLS is very hard for mortals, even just server side, and if you lose that, you lose confidentiality even if you sign messages. You also run into problems in some communities because people insist on using X.509/PKIX, and that leads to people making decisions like forcing people to install SSL servers distinct from their existing web sites to use the special certificates you force on them. Not that I know of anybody doing that . That also in turn ties back to firewalls. Push models sometimes require key exchange for allowing encryption, but experience shows people have less problems with configuring that because it's self-contained configuration. It also allows for one-way trust models that rely on the client for MITM protection. - data coordination In some applications, callbacks may be triggered to party A by a message from party B. That requires A and B share state, knowledge, pre-configuration, etc. If A and B are loosely coupled, that creates problems that push models don't have. An example is naming. I issue a certificate for Bob and you want to ask somebody else about Bob. If that somebody and I don't share the same notion of who/what Bob is, chaos ensues. An alternative model is for somebody else to push their notion of Bob to me where I can bind that information to my notion of Bobness, e.g. even if my name for Bob is Alice. --- end _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 21 12:45:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJuU-00049d-BT; Sat, 21 Oct 2006 12:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbJuS-00049X-Uf for sip@ietf.org; Sat, 21 Oct 2006 12:41:20 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbJuR-00052K-Fa for sip@ietf.org; Sat, 21 Oct 2006 12:41:20 -0400 Received: from [192.168.2.248] (pool-71-164-176-234.dllstx.fios.verizon.net [71.164.176.234]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k9LGfGTp098595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Oct 2006 11:41:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <005e01c6d820$746a3b70$5000a8c0@RW> References: <0J5L00LLRBKTJM30@jes-fe2.zx.nl> <005e01c6d820$746a3b70$5000a8c0@RW> 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: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Sat, 21 Oct 2006 12:41:18 -0400 To: Pete Cordell X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 71.164.176.234 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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've about got -04 ready to go - going through all the -03 comments to make sure they were covered - this (and Jeroen's quoted comment) need a reply. Inline: On Sep 14, 2006, at 1:08 PM, Pete Cordell wrote: > I don't think CSeq should be included either. We want information > that is invariant throughout a session. By including CSeq there's > a chance that one request doesn't have a hash collision when doing > the loop detection, but a subsequent request does. > > Pete. We already have other things going into the input that will cause the output to vary between transactions. At a minimum an initial request might not have a Route hf, where a subsequent request may: (from the draft): > This second part MUST vary with any field used by the location > service logic in > determining where to retarget or forward this request. This is > necessary to distinguish > looped requests from spirals by allowing the proxy to recognize if > none of the values > affecting the processing of the request have changed. Hence, The > second part MUST depend > at least on the received Request-URI and any Route header field > values used when processing > the received request. Implementers need to take care to include all > fields used by the > location service logic in that particular implementation. So, including the CSeq does no harm, and it could do good to avoid repeating the collision. > > ----- Original Message ----- From: "Jeroen Van Bemmel" > >> To: "Robert Sparks" >> >> Yes, except that using "the via branch" here is tricky: which one >> do you take? >> >> Pre-RFC3261 clients would not insert a branch parameter, so taking >> the top via branch wont always work. Using the branch parameter >> added by the proxy itself is possible, provided that only the >> "first part" is used. Implementors then need to make sure to >> disect the branch prior to calculating the loop hash. >> >> Possible, but easy to get wrong >> >> Jeroen That is the same concern I have had all along with the basic way this "look through the Via stack" loop detection mechanism is constructed in the first place. It's very likely that the first time implementer will do something wrong. The most frequent wrong thing I saw at SIPits back when this was mandatory the first time around was that implementations were very fragile about parsing other people's Vias, particularly the Vias of other proxies that were using the via as a convenient place to hold information about the transaction for when the response came back through (made for unusually formed, but quite legal field values). To your specific comment, my text below was ambiguous. Here's the tightened up version that I'm putting in -04. Note that this isn't asking an implementation to do _any_ dissection of a via branch parameter it didn't create (which is the confusion I think I caused you). (from the draft): > When forming the second part using a hash, > implementations SHOULD include at least one field in the input > to the hash that > varies between different transactions attempting to reach the > same destination to avoid > repeated failure should the hash collide. The Call-ID and CSeq > fields, or the first part > of the via branch parameter value the proxy is currently > constructing would be good inputs for this purpose. RjS > > -----Oorspronkelijk bericht ----- > Van: "Robert Sparks" > Aan: "Jeroen Van Bemmel" > CC: "Pete Cordell" ; "Cullen Jennings" > ; "SIP" > Verzonden: 14-9-06 15:00 > Onderwerp: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 > > Hrmm. Let me poke at that for a minute. > > You would never compare the hashes you created for two different > calls. You only compare hashes for > different instances of the _same request_ reaching the element > multiple times. The only things in the > Via stack when the request reaches you are values placed when _this > request_ went through other element, > and you're checking to see if one of them just happened to be this > element. > > The Call-ID is invariant for those comparisons. If you had a perfect > hash, including it would have no effect > on the correctness of the algorithm at all - it would be wasted > effort, which is why we were removing it. > > But for a hash that has collisions, including it, or any other set of > bits that change between requests, > shifts where you land in the hash's range, increasing the probability > that you won't encounter the _same_ > collision more than once. > > That may be exactly why call-id and cseq were included in the hash in > 3261. Assuming that's so, then > all we need are bits that change between transactions. The first part > of the via branch parameter would > be enough. > > So, I propose I add text explaining why you SHOULD (do we make this > MUST?) add some set of bits that > change between requests, and note that either the first part of the > via branch or the combination of call-id > and cseq would be good choices. > > RjS > > On Sep 14, 2006, at 5:20 AM, Jeroen Van Bemmel wrote: > >> >> I suppose one issue is that if you do happen to be the 20 billionth >> person >> trying to make such a call, then your call will fail every time, >> which may >> be a bad effect. >> >> (jvb) And THAT'S the reason to include the call-id in the hash: to >> ensure that an unlucky caller does not suffer the same fate twice >> (or rather: to make it very unlikely) >> >> 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 21 12:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbK15-0002zX-KR; Sat, 21 Oct 2006 12:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbK13-0002yY-Pg for sip@ietf.org; Sat, 21 Oct 2006 12:48:09 -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 1GbK11-0005lc-74 for sip@ietf.org; Sat, 21 Oct 2006 12:48:09 -0400 Received: from [192.168.2.248] (pool-71-164-176-234.dllstx.fios.verizon.net [71.164.176.234]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9LGlwpJ070106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Oct 2006 11:48:03 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: References: <0J5L00LLRBKTJM30@jes-fe2.zx.nl> <005e01c6d820$746a3b70$5000a8c0@RW> 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: <9C2F842E-EB42-488F-8C89-700219B6BF77@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 Date: Sat, 21 Oct 2006 12:48:00 -0400 To: Robert Sparks X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: SIP , Pete Cordell X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ARGH! Moments after hitting send and double-checking the text, I realized the text on using the first-part of the via as quoted below is horribly broken. Sorry - it was just wrong. Instead of trying to repair it to go back to the topmost via hfv (which was the original idea, and _CAN_ have the problem Jeroen was worried about, I'll simplify back to just Call-ID and CSeq. RjS On Oct 21, 2006, at 12:41 PM, Robert Sparks wrote: > I've about got -04 ready to go - going through all the -03 comments > to make sure they were covered - this (and Jeroen's quoted > comment) need a reply. > > Inline: > > On Sep 14, 2006, at 1:08 PM, Pete Cordell wrote: > >> I don't think CSeq should be included either. We want information >> that is invariant throughout a session. By including CSeq there's >> a chance that one request doesn't have a hash collision when doing >> the loop detection, but a subsequent request does. >> >> Pete. > > We already have other things going into the input that will cause > the output to vary between transactions. At a minimum an initial > request might not have a Route hf, where a subsequent request may: > (from the draft): >> This second part MUST vary with any field used by the location >> service logic in >> determining where to retarget or forward this request. This is >> necessary to distinguish >> looped requests from spirals by allowing the proxy to recognize if >> none of the values >> affecting the processing of the request have changed. Hence, The >> second part MUST depend >> at least on the received Request-URI and any Route header field >> values used when processing >> the received request. Implementers need to take care to include >> all fields used by the >> location service logic in that particular implementation. > > So, including the CSeq does no harm, and it could do good to avoid > repeating the collision. > > >> >> ----- Original Message ----- From: "Jeroen Van Bemmel" >> >>> To: "Robert Sparks" >>> >>> Yes, except that using "the via branch" here is tricky: which one >>> do you take? >>> >>> Pre-RFC3261 clients would not insert a branch parameter, so >>> taking the top via branch wont always work. Using the branch >>> parameter added by the proxy itself is possible, provided that >>> only the "first part" is used. Implementors then need to make >>> sure to disect the branch prior to calculating the loop hash. >>> >>> Possible, but easy to get wrong >>> >>> Jeroen > > That is the same concern I have had all along with the basic way > this "look through the Via stack" loop detection mechanism is > constructed in the first place. > It's very likely that the first time implementer will do something > wrong. The most frequent wrong thing I saw at SIPits back when this > was mandatory the first time around > was that implementations were very fragile about parsing other > people's Vias, particularly the Vias of other proxies that were > using the via as a convenient place to hold > information about the transaction for when the response came back > through (made for unusually formed, but quite legal field values). > > To your specific comment, my text below was ambiguous. Here's the > tightened up version that I'm putting in -04. Note that this isn't > asking an implementation to do _any_ dissection > of a via branch parameter it didn't create (which is the confusion > I think I caused you). > (from the draft): >> When forming the second part using a hash, >> implementations SHOULD include at least one field in the input >> to the hash that >> varies between different transactions attempting to reach the >> same destination to avoid >> repeated failure should the hash collide. The Call-ID and CSeq >> fields, or the first part >> of the via branch parameter value the proxy is currently >> constructing would be good inputs for this purpose. > > > RjS > >> >> -----Oorspronkelijk bericht ----- >> Van: "Robert Sparks" >> Aan: "Jeroen Van Bemmel" >> CC: "Pete Cordell" ; "Cullen Jennings" >> ; "SIP" >> Verzonden: 14-9-06 15:00 >> Onderwerp: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03 >> >> Hrmm. Let me poke at that for a minute. >> >> You would never compare the hashes you created for two different >> calls. You only compare hashes for >> different instances of the _same request_ reaching the element >> multiple times. The only things in the >> Via stack when the request reaches you are values placed when _this >> request_ went through other element, >> and you're checking to see if one of them just happened to be this >> element. >> >> The Call-ID is invariant for those comparisons. If you had a perfect >> hash, including it would have no effect >> on the correctness of the algorithm at all - it would be wasted >> effort, which is why we were removing it. >> >> But for a hash that has collisions, including it, or any other set of >> bits that change between requests, >> shifts where you land in the hash's range, increasing the probability >> that you won't encounter the _same_ >> collision more than once. >> >> That may be exactly why call-id and cseq were included in the hash in >> 3261. Assuming that's so, then >> all we need are bits that change between transactions. The first part >> of the via branch parameter would >> be enough. >> >> So, I propose I add text explaining why you SHOULD (do we make this >> MUST?) add some set of bits that >> change between requests, and note that either the first part of the >> via branch or the combination of call-id >> and cseq would be good choices. >> >> RjS >> >> On Sep 14, 2006, at 5:20 AM, Jeroen Van Bemmel wrote: >> >>> >>> I suppose one issue is that if you do happen to be the 20 billionth >>> person >>> trying to make such a call, then your call will fail every time, >>> which may >>> be a bad effect. >>> >>> (jvb) And THAT'S the reason to include the call-id in the hash: to >>> ensure that an unlucky caller does not suffer the same fate twice >>> (or rather: to make it very unlikely) >>> >>> 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 >> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 21 13:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbKLK-0003jE-Kk; Sat, 21 Oct 2006 13:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbKLJ-0003iC-Ho for sip@ietf.org; Sat, 21 Oct 2006 13:09:05 -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 1GbKG6-0007Nc-Uz for sip@ietf.org; Sat, 21 Oct 2006 13:03:44 -0400 Received: from [192.168.2.248] (pool-71-164-176-234.dllstx.fios.verizon.net [71.164.176.234]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9LH3bBC071596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 21 Oct 2006 12:03:42 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <20DEC26E-6C03-4163-867B-C1546EC5B0D5@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP List From: Robert Sparks Date: Sat, 21 Oct 2006 13:03:39 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Sip] loop-fix-04 submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 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 just submitted http://www.nostrum.com/~rjsparks/draft-ietf-sip- fork-loop-fix-04.txt to the repository. This captures all of the WG last call comments. 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 Sun Oct 22 19:57:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbn9i-00039G-Sc; Sun, 22 Oct 2006 19:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbn9h-000381-Lk; Sun, 22 Oct 2006 19:55:01 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbn9f-0001Gv-PM; Sun, 22 Oct 2006 19:55:01 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 18:54:55 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 22 Oct 2006 18:54:54 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Oct 2006 18:54:54 -0500 Message-ID: From: "Thomson, Martin" To: "Jeroen van Bemmel" , Date: Sun, 22 Oct 2006 18:54:52 -0500 Subject: RE: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-05.txt MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Oct 2006 23:54:54.0216 (UTC) FILETIME=[78829080:01C6F635] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <005601c6f412$442d0e70$0601a8c0@BEMBUSTER> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-05.txt Thread-Index: Acb0Ek5T8PD0A0OGQtG35mueHSlCFgCIMkAg X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: geopriv@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="===============1703242587==" Errors-To: sip-bounces@ietf.org --===============1703242587== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message VGhlIGV4dHJhIFBJREYtTE8gdGFnIGlzIHRoZSBvbmx5IGZlYXR1cmUgb2YgdGhlIGRyYWZ0IHRo YXQgSSBoYXZlIGEgcHJvYmxlbSB3aXRoLiAgVGhpcyBzZWVtcyBsaWtlIGEgY2FzZSB3aGVyZSB0 aGUgbGV0dGVyIG9mIHRoZSBsYXcgaXMgdGFrZW4gb3ZlciB0aGUgc3Bpcml0IG9mIHRoZSBsYXcu DQoNCkkgYWdyZWUgd2l0aCBKZXJvZW4gaW4gdGhhdCBhIFNJUCBwcm94eSBzaG91bGQgbm90IGhh dmUgdG8gY2hhbmdlIGl0cyBiZWhhdmlvdXIuICBXaGF0IHdvdWxkIGJlIG1vcmUgc2Vuc2libGUg aXMgdG8gYWNrbm93bGVkZ2UgdGhhdCBhIFNJUCBtZXNzYWdlIHdpdGggYW4gdW5lbmNyeXB0ZWQg Ym9keSBjYW4gYmUgc2VlbiBieSBhbGwgcHJveGllcy4gIEJ5IGluY2x1ZGluZyBhIFBJREYtTE8g aW4gdGhpcyB3YXksIHlvdSBfaW1wbGljaXRseV8gZ2l2ZSBwcm94aWVzIHBlcm1pc3Npb24gdG8g Zm9yd2FyZCBpdC4gIFlvdSBkb24ndCBuZWVkIHNwZWNpYWwgdGFncyBmb3IgdGhhdC4gIFRoYXQg Y292ZXJzIHRoZSBsYXJnZSBudW1iZXIgb2YgcHJveGllcyB0aGF0IGRvbid0IGNhcmUsIHRoYXQg aGF2ZW4ndCBiZWVuIHVwZ3JhZGVkLCBvciB0aGF0IHdpbGwgbm90IGJlIHVwZ3JhZGVkLg0KDQpJ IGFsc28gZG9uJ3QgbGlrZSB0aGUgaWRlYSB0aGF0IHRoaXMgdXBkYXRlcyBSRkMgNDExOSB3aXRo b3V0IHNheWluZyBpdC4NCg0Kfg0KTWFydGluDQoNCiogTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0 IHRoZSAicm91dGluZy1xdWVyeS1hbGxvd2VkIiB0YWcgb25seSBhcHBsaWVzIHRvIGJ5LXZhbHVl OyBhIGJ5LXJlZmVyZW5jZSBVUkkgY2FuIGJlIGZvcndhcmRlZCB3aXRob3V0IGNvbmNlcm5zKiou DQoNCioqIFRoZXJlIGFyZSBub3cgY2FzZXMgd2hlcmUgdGhpcyBtYXkgbm8gbG9uZ2VyIGJlIHRy dWUuLi4gRkZTLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEplcm9l biB2YW4gQmVtbWVsIFttYWlsdG86amJlbW1lbEB6b25uZXQubmxdDQo+IFNlbnQ6IEZyaWRheSwg MjAgT2N0b2JlciAyMDA2IDQ6MzggUE0NCj4gVG86IHNpcEBpZXRmLm9yZw0KPiBDYzogZ2VvcHJp dkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbR2VvcHJpdl0gUmU6IFtTaXBdIEktREFDVElPTjpkcmFm dC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLQ0KPiAwNS50eHQNCj4gDQo+ICJUaGUgZW50 aXRpZXMgcmVjZWl2aW5nIGxvY2F0aW9uIE1VU1Qgb2JleSB0aGUgcHJpdmFjeSBhbmQgc2VjdXJp dHkgcnVsZXMNCj4gaW4NCj4gdGhlIFBJREYtTE8gYXMgZGVzY3JpYmVkIGluIFJGQzQxMTksIHJl Z2FyZGluZyByZXRyYW5zbWlzc2lvbiBhbmQNCj4gcmV0ZW50aW9uLiINCj4gDQo+IERvZXMgdGhp cyBtZWFuIHRoYXQgYSBTSVAgcHJveHkgcmVjZWl2aW5nIGEgcmVxdWVzdCB3aXRoIGEgR2VvbG9j YXRpb24NCj4gbXVzdA0KPiBmaXJzdCBpbnNwZWN0IHRoZSBsb2NhdGlvbiBvYmplY3QgYmVmb3Jl IGZvcndhcmRpbmc/IEZvcg0KPiBsb2NhdGlvbi1ieS1yZWZlcmVuY2UsIHRoaXMgbWF5IGludHJv ZHVjZSBhbiB1bmFjY2VwdGFibGUgZGVsYXksDQo+IGVzcGVjaWFsbHkNCj4gd2hlbiB0aGUgcHJv eHkgZG9lcyBub3QgZG8gYW55dGhpbmcgd2l0aCB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gaXRz ZWxmLg0KPiANCj4gUHJveGllcyB0aGF0IGRvbid0IHVuZGVyc3RhbmQgR2VvbG9jYXRpb24gd2ls bCBmb3J3YXJkIGFzIHVzdWFsLCBwb3NzaWJseQ0KPiB2aW9sYXRpbmcgdGhlIGZvcndhcmRpbmcg cG9saWN5LiBZb3UgbWF5IHdhbnQgdG8gc3BlbmQgc29tZSB3b3JkcyBvbiB0aGlzLg0KPiBGb3Ig cHJveGllcyB0aGF0IGRvIHVuZGVyc3RhbmQsIHlvdSBjb3VsZCBjb25zaWRlciBpbnNlcnRpbmcg YSBmbGFnIGluIGENCj4gU0lQDQo+IEdlb2xvY2F0aW9uIGhlYWRlciBmb3IgdGhlIGJ5LXJlZmVy ZW5jZSBjYXNlLCBzdWNoIHRoYXQgYSBkZXJlZmVyZW5jZSBpcw0KPiBub3QNCj4gbmVlZGVkIHRv IG9idGFpbiB0aGUgcG9saWN5DQo+IA0KPiBSZWdhcmRzLA0KPiBKZXJvZW4NCj4gDQo+IEludGVy bmV0LURyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gPj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4+IGRpcmVjdG9y aWVzLg0KPiA+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgV29ya2luZw0KPiA+PiBHcm91cCBvZiB0aGUgSUVURi4NCj4gPj4NCj4g Pj4gVGl0bGUgOiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgTG9jYXRpb24gQ29udmV5YW5j ZQ0KPiA+PiBBdXRob3IocykgOiBKLiBQb2xrLCBCLiBSb3Nlbg0KPiA+PiBGaWxlbmFtZSA6IGRy YWZ0LWlldGYtc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UtMDUudHh0DQo+ID4+IFBhZ2VzIDogMjYN Cj4gPj4gRGF0ZSA6IDIwMDYtMTAtMTkNCj4gPj4NCj4gPj4gVGhpcyBkb2N1bWVudCBkZWZpbmVz IGFuIGV4dGVuc2lvbiB0byB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uDQo+ID4+ICAgUHJvdG9jb2wg KFNJUCkgdG8gY29udmV5IGdlb2dyYXBoaWMgbG9jYXRpb24gaW5mb3JtYXRpb24gZnJvbSBvbmUN Cj4gPj4gICBTSVAgZW50aXR5IHRvIGFub3RoZXIgU0lQIGVudGl0eS4gIFRoZSBleHRlbnNpb24g Y292ZXJzIGVuZCB0byBlbmQNCj4gPj4gICBjb252ZXlhbmNlIGFzIHdlbGwgYXMgbG9jYXRpb24t YmFzZWQgcm91dGluZywgd2hlcmUgcHJveHkgc2VydmVycw0KPiA+PiAgIG1ha2Ugcm91dGluZyBk ZWNpc2lvbnMgYmFzZWQgb24gdGhlIGxvY2F0aW9uIG9mIHRoZSBVQUMuDQo+ID4+DQo+ID4+IEEg VVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiA+PiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLQ0KPiAw NS50eHQNCj4gPj4NCj4gPj4gVG8gcmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEktRCBBbm5vdW5j ZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8NCj4gPj4gaS1kLWFubm91bmNlLXJlcXVlc3RA aWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1bnN1YnNjcmliZSBpbiB0aGUgYm9keQ0KPiA+PiBvZg0K PiA+PiB0aGUgbWVzc2FnZS4NCj4gPj4gWW91IGNhbiBhbHNvIHZpc2l0DQo+ID4+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZQ0KPiA+PiB0byBjaGFu Z2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuDQo+ID4+DQo+ID4+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4gd2l0aCB0aGUNCj4g Pj4gdXNlcm5hbWUgImFub255bW91cyIgYW5kIGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwgYWRk cmVzcy4gQWZ0ZXINCj4gPj4gbG9nZ2luZyBpbiwgdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBh bmQgdGhlbg0KPiA+PiAiZ2V0IGRyYWZ0LWlldGYtc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UtMDUu dHh0Ii4NCj4gPj4NCj4gPj4gQSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3RvcmllcyBj YW4gYmUgZm91bmQgaW4NCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiA+ PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+Pg0KPiA+ PiBJbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLg0KPiA+Pg0K PiA+PiBTZW5kIGEgbWVzc2FnZSB0bzoNCj4gPj4gbWFpbHNlcnZAaWV0Zi5vcmcuDQo+ID4+IElu IHRoZSBib2R5IHR5cGU6DQo+ID4+ICJGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1z aXAtbG9jYXRpb24tY29udmV5YW5jZS0wNS50eHQiLg0KPiA+Pg0KPiA+PiBOT1RFOiBUaGUgbWFp bCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1lbnQgaW4NCj4gPj4gTUlN RS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlz DQo+ID4+IGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3Jl IHRoZSAiRklMRSINCj4gPj4gY29tbWFuZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlv dSB3aWxsIG5lZWQgIm11bnBhY2siIG9yDQo+ID4+IGEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFk ZXIuICBEaWZmZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJzDQo+ID4+IGV4aGliaXQg ZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRoDQo+ID4+ICJt dWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBz cGxpdA0KPiA+PiB1cCBpbnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2Nh bCBkb2N1bWVudGF0aW9uIG9uDQo+ID4+IGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2Vz Lg0KPiA+Pg0KPiA+PiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUg Y29tcGxpYW50IG1haWwgcmVhZGVyDQo+ID4+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2Fs bHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQo+ID4+IEludGVybmV0LURyYWZ0 Lg0KPiA+Pg0KPiA+DQo+ID4NCj4gPg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCj4gPj4gVGhpcyBsaXN0IGlzIGZvciBORVcg ZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29sDQo+ID4+IFVzZSBzaXAtaW1wbGVt ZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJlbnQgc2lwDQo+ID4+ IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNh dGlvbiBvZiBzaXANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9y IHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdl ZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQpp bW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNl IG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClttZjJd --===============1703242587== 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 --===============1703242587==-- From sip-bounces@ietf.org Mon Oct 23 02:31:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtHI-0002zh-UH; Mon, 23 Oct 2006 02:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbtFZ-0008UW-0m for sip@ietf.org; Mon, 23 Oct 2006 02:25:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbt3d-0007wH-4V for sip@ietf.org; Mon, 23 Oct 2006 02:13:11 -0400 Received: by nf-out-0910.google.com with SMTP id n15so2414131nfc for ; Sun, 22 Oct 2006 23:13:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gqVG+FIZoe3RF8PSEzacZ3+pXQtYGSYEdEZX3Ysa3ODkNVA1i2gW/UwHAmkKV/WsONBnjA/nWhmj2eiERp1GSocVB/apzmISasfZsMoRvpA6N/jx3AUaL21sbymXk0m+rEe2S/cDXRIG4pPV1T/SrDB68mH7z7gkU/sSXMN656Y= Received: by 10.78.128.11 with SMTP id a11mr6823642hud; Sun, 22 Oct 2006 23:13:08 -0700 (PDT) Received: by 10.78.153.16 with HTTP; Sun, 22 Oct 2006 23:13:08 -0700 (PDT) Message-ID: Date: Sun, 22 Oct 2006 23:13:08 -0700 From: "Jason Fischl" To: joel.repiquet@tech-invite.com Subject: Re: [Sip] WGLC: draft-ietf-sip-certs-01 In-Reply-To: <200610101106.k9AB6DTg022859@gate01.nexlink.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200610101106.k9AB6DTg022859@gate01.nexlink.ch> X-Google-Sender-Auth: d6888ba99845cadf X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: sip@ietf.org, fluffy@cisco.com, jon.peterson@neustar.biz X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Many thanks for your comments and sorry for the delay in responding. See inline for my detailed responses. On 10/10/06, Jo=EBl Repiquet wrote: > In "3. Overview": > --------------- > > There are in Bob's domain 3 servers: Proxy, Auth and Cred. > > Page 7, when: > "Alice decides that she wishes to discover Bob's > certificate, Alice's UA sends a SUBSCRIBE message to Bob's AOR. > The proxy in Bob's domain routes this to the credential server > via an authorization service". > > What do you mean by "authorization service"? conversely to the > "authentication service" and the "credential service" there is no > clear standardization of it for SIP. Is it related > to some trait-based mechanism? what would be its > role in this very case and why not to have the proxy route > the SUBSCRIBE request directly to the credential server? > We meant Authentication Service as defined in RFC 4474. Updated text here: Some time later Alice decides that she wishes to discover Bob's certificate so that she can send him an encrypted message or so that she can verify the signature on a message from Bob. Alice's UA sends a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes this to the credential server via an "authentication service" as defined in [2]. The credential server returns a NOTIFY that contains Bob's public certificate in the body. This is routed through an authentication service that signs that this message really can validly claim to be from the AOR "sip:bob@example.com". Alice's UA receives the certificate and can use it to encrypt a message to Bob. > Likewise, in the same paragraph: > "The credential server returns a NOTIFY that contains Bob's public > certificate in the body. This is routed through an authentication > service that signs that this message really can validly claim to be > from the AOR "sip:bob@example.com". Alice's UA receives the > certificate and can use it to encrypt a message to Bob." > > According to the figure page 6, the "authentication service" is provided = by > the same server as the "authorization service". Typically, it would be > provided -- as a general service for the domain -- by the Proxy. > Is not the Auth server superfluous, or is there any reason we need one? > The "authentication service" is the RFC 4474 identity service and could be provided by the proxy. I think the text in this paragraph is ok once we made the changes as provided above. > > In "8. Examples": > ---------------- > > In 8.1 we see that the authentication service is provided by the Credenti= al > server. I would add a "date" header since it is mandatory. > Since many other headers are not included in this example, I don't think the Date is necessary here. > > In 8.2, first paragraph: > > "When Alice's UA wishes to publish Alice's public and private keys to > the credential service, it sends a PUBLISH request like the one > below. This must be sent over a TLS connection in which the other > end of the connection presents a certificate that matches the > credential service for Alice and digest challenges the request to > authenticate her." > > What do you mean by "that matches the credential service"? the TLS server > certificate is not related to the credential service. You raise a valid point. Here's some alternate text: When Alice's UA wishes to publish Alice's public and private keys to the credential service, it sends a PUBLISH request like the one below. This must be sent over a TLS connection directly to the domain of the credential service. The credential service presents a certificate where the subjectAltName contains an entry that matches the domain name in the request line of the PUBLISH request and digest challenges the request to authenticate her. > > In the PUBLISH request, I would add the header: > Event: credential > added PUBLISH sips:alice@atlanta.example.com SIP/2.0 ... Event: credential Content-Type: multipart/mixed;boundary=3Dboundary Content-Disposition: signal > > Editorial remarks: > ----------------- > > In "1. Introduction" (2nd paragraph): > Replace: > In addition, this specification provides a which mechanism allows SIP > by: > In addition, this specification provides a mechanism that allows SIP > done > > In "4. UA Behavior with Certificates" (last paragraph): > Replace: > be valid and legal for that UA to send a 302 redirecting the call to > Charlie. > by: > be valid and legal for that UA to send a 302 redirecting the call to > Bob. > done > > In "6.5. NOTIFY Bodies": > Replace: > other type. The Content-Disposition MUST be set to "signal", as > defined in as defined in [16]. > by: > other type. The Content-Disposition MUST be set to "signal", as > defined in [16]. > done > > In "12. References": replace [2] and [19] by: > > [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated > Identity Management in the Session Initiation Protocol (SIP)", > RFC 4474, August 2006. > > [19] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation > Protocol (SIP) Event Notification Extension for Resource Lists", > RFC 4662, August 2006. > done _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 23 16:46:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6eL-0004LV-QQ; Mon, 23 Oct 2006 16:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6cu-0001eF-Tb; Mon, 23 Oct 2006 16:42: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 1Gc6cu-0003wD-PL; Mon, 23 Oct 2006 16:42:28 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gc6cu-0002Xv-82; Mon, 23 Oct 2006 16:42:28 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 0BB91175B8; Mon, 23 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5o9-0008NB-Jm; Mon, 23 Oct 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: Mon, 23 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-fork-loop-fix-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 : Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Author(s) : R. Sparks, et al. Filename : draft-ietf-sip-fork-loop-fix-04.txt Pages : 13 Date : 2006-10-23 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop-fix-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-fork-loop-fix-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-fork-loop-fix-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-10-23105205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-fork-loop-fix-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-fork-loop-fix-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23105205.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 Oct 23 20:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcATj-0002fp-7E; Mon, 23 Oct 2006 20:49:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcATh-0002fE-TH for sip@ietf.org; Mon, 23 Oct 2006 20:49:13 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcATd-0003OM-HA for sip@ietf.org; Mon, 23 Oct 2006 20:49:13 -0400 Received: by wr-out-0506.google.com with SMTP id i20so432050wra for ; Mon, 23 Oct 2006 17:49:09 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=JKPiesyArsNct6ZuIs3exnn60wjSHTpz2tVD0nqektLgZX3gWcdxrRyWgm2Qf7DF6BW9g3Ob1U4iPsZSsewi3YJ+2VPezFoceos+pKcAlzX9rwxtwBM2F8AgLt0Z1kgo4WulrwUb6SGNkr0xFXy9Tx/S64BvIRJoktjH5ECv2Mk= Received: by 10.78.157.8 with SMTP id f8mr8344986hue; Mon, 23 Oct 2006 17:49:08 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Mon, 23 Oct 2006 17:49:08 -0700 (PDT) Message-ID: <953beacc0610231749k13039111qeb19f20e3112bced@mail.gmail.com> Date: Mon, 23 Oct 2006 17:49:08 -0700 From: "Rohan Mahy" To: sip MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Rohan Mahy Subject: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Folks, Yesterday I did an extremely belated, but very detailed update to outbound. I believe that I have incorporated all the changes we discussed at the Montreal meeting and the consenus reached on the mailing list regarding STUN. I also incorporated a new short section explaining how STUN keepalives would work with SigComp, as well as many clarifications from private comments. There are a few new changes which are listed as potential issues at the bottom of this email. I introduced a new status code instead of using 480 or 410, I added a new timer to determine when a flow is stable to make sure that the avalanche restart prevention really works, and I changed the text about which nodes have to add a Path header or store the previous hop flow information. Please especially read through these. If you like these changes please send me a quick email to that effect. If not please send proposed changes. Until the draft appears in the archives, you can get it here: http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-05.txt http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-05.html thanks, -rohan Changes from outbound-04 to -05: STUN-related changes: Moved STUN Keepalive description to a separate section (section 8). Referenced this section from within the relevant sections in the rest of the document. Added language clarifying that UA MUST NOT send STUN without an explicit indication the server supports STUN, and that a UA MUST stop sending STUN if it appears the server does not support it (ex:initial STUN request fails). Defined a 'sip-stun' option tag. UAs can optionally probe servers for it with OPTIONS. Clarified that UAs SHOULD NOT put this in a Proxy-Require. Explain that the first-hop MUST support this option-tag. Clarify that STUN done in conjuction with SIP over TLS is on the "inside" of the TLS record-layer. Added a new section explaining the how STUN keepalives are used with Sigcomp-compressed SIP messages. STUN is "outside" the compression layer for UDP, but wrapped inside the well-known shim header for TCP-based transports. Non-STUN changes: Change a MUST to SHOULD based on consensus at last meeting. The UAC SHOULD register a flow for each member of the outbound-proxy-set. Added comment about reregistration typically happening over same flow as original registration. Consistent with my email proposal about Slides 9 and 10 from IETF66, I added text about the 'ob' parameter which is used in Path header field URIs to make sure that the previous proxy that added a Path understood outbound processing. The registrar doesn't include Supported: outbound unless it could actually do outbound processing (ex: any Path headers have to have the 'ob' parameter). Added some text describing what a registration means when there is an instance-id, but no reg-id. This is necessary to make GRUU work for example. Reworded registrar and proxy in some places (introduce the term "Authoritative Proxy"). Several folks pointed out that we were being sloppy with the proxy accepting register requests and the registrar forward requests. I think these are all fixed now. ISSUE: Changed 410 Gone to new response code 430 Flow Failed. Based on consensus at the last meeting, I was going to change this to 480 Temporarily Unavailable. Unfortunately this would not work. A phone that uses 480 today for the suggested purpose of saying "Do Not Disturb" would trigger the authoritative proxy to delete all the flows of that phone. Oops! I'm hoping this is fine with everyone. ISSUE: Clarified how to decide what a consecutive registration timer is. Proposal in the draft is that a flow must be stable for some time (default 120 seconds) otherwise previous registration is not considered successful. Are folks OK with this? ISSUE: Loosened restrictions on always storing a complete Path vector back to the registrar/authoritative proxy if a previous hop in the path vector is reachable. This was one of the biggest problems with the draft. Now it is pretty clear how you can build an archtiecture where the registrar is separate from the authoritative proxy, and also clear how you can visit several edge proxies, but not all of them have to be in the Path. Please read this wording carefully in Section 5.1 and Section 6. Is this OK? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 01:25:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcEjj-0003Q3-Sp; Tue, 24 Oct 2006 01:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcEjh-0003IS-NV for sip@ietf.org; Tue, 24 Oct 2006 01:22: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 1GcEjd-0005ff-U4 for sip@ietf.org; Tue, 24 Oct 2006 01:22:01 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2006 22:21:57 -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 k9O5LvNZ032069 for ; Mon, 23 Oct 2006 22:21:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9O5LuW6024041 for ; Mon, 23 Oct 2006 22:21:57 -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); Mon, 23 Oct 2006 22:21:57 -0700 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 22:21:56 -0700 Message-ID: <453DA2F3.1070009@cisco.com> Date: Tue, 24 Oct 2006 01:21:55 -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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 05:21:56.0942 (UTC) FILETIME=[52FAAEE0:01C6F72C] DKIM-Signature: a=rsa-sha1; q=dns; l=3719; t=1161667317; x=1162531317; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Updated=20GRUU=20spec=20-=20big=20changes; X=v=3Dcisco.com=3B=20h=3DnmctTXQ7k8IMgMmdNjRhk9WyvAw=3D; b=CekrJXnOlmoQ1bdk9uNJA3wuiQXPKKGbxXVC1ESesZwDHRmog5yKZjdEuxUx17DQHUdo31JF xcd+HQUThDXgP/W1yuQduqlLM/80G8RkC58QvnQEJJ1JUkWogRPDw3kx; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Sip] Updated GRUU spec - big changes X-BeenThere: sip@ietf.org X-Mailman-Version: 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 submitted an update to the GRUU spec. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-gruu-11.txt This document represents some very major changes from -10. A design team has been working extensively over the last month or so, and this represents the current output of that work. Besides being more or less a rewrite, the changes include: * Top-down rewrite of the document. New introduction from EKR. Normative text moved around to be clearer. Redundant stuff removed. Sections combined. Removed arcane discussion on URI properties. Removed the arcane UML model and replaced it with a more intuitive diagram on relationships. * added "anonymous gruu", known as temporary gruu. A temporary GRUU is assigned when you first register a contact, and an additional one is created on each refresh. All of the ones accumulated over the lifetime of the registration remain valid. Each of them obfuscate the AOR and instance ID. Added a description of a stateless algorithm for computing these. Lengthy discussion on the privacy implications of using them. * removed completely the grid concept and associated processing. The plan is to instead use loose routing or an alternative like it which would allow a UA to add params to an AOR or a GRUU and get them back in a request it receives. * changed name of 'gruu' URI parameter to 'gr'. This parameter can now take a value, folding in the functionality of 'opaque'. Removed the opaque parameter. * removed SIPS related processing rules * introduced this concept of self-made GRUU, which was there before but kind of vague. This is to address Robert's concern about always having proxies in the loop. A self-made GRUU is one constructed by a UA using its IP address or hostname as the domain part of a SIP URI. * added a check in an originating proxy to make sure that the GRUU in the INVITE matches the identity of the requestor. THis prevents an attack whereby a malicious user could cause mid-dialog requests sent by their peer to be targeted to a DoS target. * softened requirements around record-routing for home proxies. The final algorithm differs for the originating and terminating sides. On originating, if the request has a GRUU in the contact the home proxy record routes. On terminating, it record routes if the URI in the request URI is bound to a contact that has a GRUU. Other proxies in the domain can do what they want. Some guidance is given on what a proxy would see if it does or doesnt record route. * added rules for tel URI handling * removed bit about registering different contacts to each AOR when a UA has multiple AOR; will leave that to the UA loose route spec * added requirement that contact cannot be weakly equivalent to AOR; this deals with the GRUU loop problem (where a UA registers its own GRUU as a contact with the instance ID associated with the GRUU, causing the GRUU to resolve to itself). Previously, this was solved by prohibiting the contact from being a GRUU. However, there are valid cases for this when registering a instance in one domain to another domain. This new rule allows this. * Further clarifications on outbound proxies and gruu interactions -- 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 Oct 24 02:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcG9q-0007j1-5U; Tue, 24 Oct 2006 02:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcG9o-0007dx-Qx for sip@ietf.org; Tue, 24 Oct 2006 02:53:04 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcG9n-0005oE-Fy for sip@ietf.org; Tue, 24 Oct 2006 02:53:04 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 114C2AC37E; Tue, 24 Oct 2006 09:52:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17725.47177.957929.445888@harjus.tutpro.com> Date: Tue, 24 Oct 2006 09:52:57 +0300 To: "Rohan Mahy" Subject: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 In-Reply-To: <953beacc0610231749k13039111qeb19f20e3112bced@mail.gmail.com> References: <953beacc0610231749k13039111qeb19f20e3112bced@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 rohan, does this new draft take into account what jonathan prposed here: draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt for example, regarding discovery of outbound proxy set? -- 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 Tue Oct 24 03:29:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGfs-0000w3-20; Tue, 24 Oct 2006 03:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcGfq-0000vy-RD for sip@ietf.org; Tue, 24 Oct 2006 03:26:10 -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 1GcGfm-0006kV-Bz for sip@ietf.org; Tue, 24 Oct 2006 03:26:10 -0400 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7M00ICGPZS4R@siemenscomms.co.uk> for sip@ietf.org; Tue, 24 Oct 2006 08:26:16 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGX2XW>; Tue, 24 Oct 2006 08:26:05 +0100 Content-return: allowed Date: Tue, 24 Oct 2006 08:26:02 +0100 From: "Elwell, John" To: "Drage, Keith (Keith)" , SIP Message-id: <50B1CBA96870A34799A506B2313F26670A300523@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: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [Sip] RE: I-D ACTION:draft-drage-sip-essential-correction-00.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 Keith, In section 3 it states: "At an appropriate period time, an editor working on behalf of the SIP working group will compile all changes that have successfully completed working group last call into a internet draft, along with the contents of all previous documents that update the SIP RFC requiring correction. The internet draft will be submitted to IESG as a proposed standards track RFC for approval for publication, without any further working group last call." Just to be clear, this I-D is a compilation of changes, not a copy of the original RFC with changes applied? Therefore this I-D will update the original RFC, and not obsolete it? Other documents that reference the original RFC can still continue to do so? Is there a plan to trawl all previously reported bugs to see which are eligible for dealing with in this way? Would you consider my draft-elwell-sipping-update-pai would qualify for this process? I guess not, as it concerns an informational RFC that is the responsibility of SIPPING. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 18 October 2006 20:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-drage-sip-essential-correction-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Process for Handling Essential > Corrections to the Session Initiation Protocol (SIP) > Author(s) : K. Drage > Filename : draft-drage-sip-essential-correction-00.txt > Pages : 11 > Date : 2006-10-18 > > The Session Initial Protocol (SIP) defined in RFC 3261 and a large > number of extensions forms a considerable body of work, > which through > sheer size has a number of errors that require correction. This > document explains the process for managing essential corrections to > SIP. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-drage-sip-essential- > correction-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-drage-sip-essential-correction-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-drage-sip-essential-correction-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 04:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHre-0002KI-AU; Tue, 24 Oct 2006 04:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHrc-0002KD-QN for sip@ietf.org; Tue, 24 Oct 2006 04:42:24 -0400 Received: from [218.189.109.26] (helo=soln-sro192.solutionip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcHrb-0005Z6-4N for sip@ietf.org; Tue, 24 Oct 2006 04:42:24 -0400 Received: from [10.0.49.63] (helo=[127.0.0.1]) by soln-sro192.solutionip.com with esmtp (Exim 3.34 #1) id 1GcHra-0006J9-00 for sip@ietf.org; Tue, 24 Oct 2006 16:42:22 +0800 Message-ID: <453DD1C4.7080005@neustar.biz> Date: Tue, 24 Oct 2006 01:41:40 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Subject: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications (was: Re: [Sip] comments on draft-ietf-sip-saml-00) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tschofenig, Hannes wrote: > >> * I'm not clear on how this mechanism works with older sip-identity >> implementations. The main issue is whether the URI in the identity-info >> header field will return just a certificate, as specified in sip-identity, >> or whether it returns a saml assertion. An older sip-identity verifier >> will expect a certificate but it will get an assertion if the AS >> implements sip-saml. Perhaps you are assuming that the Accept headers or >> something are used for this? Somehow this needs to be handled. > > My understanding was that this got fixed with the SIP Identity draft. I > might, however, be worth to double-check it. I double-checked it, and I think we perhaps have an issue here. I see that the language of interest has now changed from (bottom of page 14 in -sip-identity-06).. The 'absoluteURI' portion of the Identity-Info header MUST contain either an HTTP or HTTPS URI which dereferences to a resource that contains a single MIME body containing the certificate of the authentication service. These URIs MUST follow the conventions of RFC2585 [10] and the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. ... ..to this at the beginning of the second para of page 15 (in RFC4474).. The 'absoluteURI' portion of the Identity-Info header MUST contain a URI which dereferences to a resource containing the certificate of the authentication service. All implementations of this specification MUST support the use of HTTP and HTTPS URIs in the Identity-Info header. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. ... Given the revised text above, I'm a tad concerned that implementors will interpret the 3d sentence to mean that their implementations need _only_ support HTTP/HTTPS URIs pointing to certificates as described in RFC2585, even though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs pointing at resources other than certificates and/or CRL files are alloFrom sip-bounces@ietf.org Tue Oct 24 04:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHre-0002KI-AU; Tue, 24 Oct 2006 04:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHrc-0002KD-QN for sip@ietf.org; Tue, 24 Oct 2006 04:42:24 -0400 Received: from [218.189.109.26] (helo=soln-sro192.solutionip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcHrb-0005Z6-4N for sip@ietf.org; Tue, 24 Oct 2006 04:42:24 -0400 Received: from [10.0.49.63] (helo=[127.0.0.1]) by soln-sro192.solutionip.com with esmtp (Exim 3.34 #1) id 1GcHra-0006J9-00 for sip@ietf.org; Tue, 24 Oct 2006 16:42:22 +0800 Message-ID: <453DD1C4.7080005@neustar.biz> Date: Tue, 24 Oct 2006 01:41:40 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Subject: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications (was: Re: [Sip] comments on draft-ietf-sip-saml-00) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Tschofenig, Hannes wrote: > >> * I'm not clear on how this mechanism works with older sip-identity >> implementations. The main issue is whether the URI in the identity-info >> header field will return just a certificate, as specified in sip-identity, >> or whether it returns a saml assertion. An older sip-identity verifier >> will expect a certificate but it will get an assertion if the AS >> implements sip-saml. Perhaps you are assuming that the Accept headers or >> something are used for this? Somehow this needs to be handled. > > My understanding was that this got fixed with the SIP Identity draft. I > might, however, be worth to double-check it. I double-checked it, and I think we perhaps have an issue here. I see that the language of interest has now changed from (bottom of page 14 in -sip-identity-06).. The 'absoluteURI' portion of the Identity-Info header MUST contain either an HTTP or HTTPS URI which dereferences to a resource that contains a single MIME body containing the certificate of the authentication service. These URIs MUST follow the conventions of RFC2585 [10] and the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. ... ..to this at the beginning of the second para of page 15 (in RFC4474).. The 'absoluteURI' portion of the Identity-Info header MUST contain a URI which dereferences to a resource containing the certificate of the authentication service. All implementations of this specification MUST support the use of HTTP and HTTPS URIs in the Identity-Info header. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert' described in that specification. ... Given the revised text above, I'm a tad concerned that implementors will interpret the 3d sentence to mean that their implementations need _only_ support HTTP/HTTPS URIs pointing to certificates as described in RFC2585, even though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs pointing at resources other than certificates and/or CRL files are allowable, as long as the resource resolves one way or another into a "..certificate of the authentication service" (1st sentence above) -- as in a URI pointing to a SAML assertion containing such a cert. thoughts? thanks, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 04:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHoG-0001Z8-92; Tue, 24 Oct 2006 04:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHoE-0001Uh-JG for sip@ietf.org; Tue, 24 Oct 2006 04:38:55 -0400 Received: from [218.189.109.26] (helo=soln-sro192.solutionip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcHcn-0002CG-9E for sip@ietf.org; Tue, 24 Oct 2006 04:27:06 -0400 Received: from [10.0.49.63] (helo=[127.0.0.1]) by soln-sro192.solutionip.com with esmtp (Exim 3.34 #1) id 1GcHcm-0005WG-00 for sip@ietf.org; Tue, 24 Oct 2006 16:27:04 +0800 Message-ID: <453DCE2D.4020806@neustar.biz> Date: Tue, 24 Oct 2006 01:26:21 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] SIP SAML: Issue #5 - Replay Protection: SIP specific Fields in the SAML Assertion References: <45323D22.7090700@gmx.net> In-Reply-To: <45323D22.7090700@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 Hannes Tschofenig wrote: > > I agree with Jonathan's observation. We should define some new fields > that can be carried in the SAML assertion and address this threat. agreed. We need to be careful about how retargeting and forking might affect what sort of info we include in the SAML Assertion, yes? =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip wable, as long as the resource resolves one way or another into a "..certificate of the authentication service" (1st sentence above) -- as in a URI pointing to a SAML assertion containing such a cert. thoughts? thanks, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 04:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHoG-0001Z8-92; Tue, 24 Oct 2006 04:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcHoE-0001Uh-JG for sip@ietf.org; Tue, 24 Oct 2006 04:38:55 -0400 Received: from [218.189.109.26] (helo=soln-sro192.solutionip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcHcn-0002CG-9E for sip@ietf.org; Tue, 24 Oct 2006 04:27:06 -0400 Received: from [10.0.49.63] (helo=[127.0.0.1]) by soln-sro192.solutionip.com with esmtp (Exim 3.34 #1) id 1GcHcm-0005WG-00 for sip@ietf.org; Tue, 24 Oct 2006 16:27:04 +0800 Message-ID: <453DCE2D.4020806@neustar.biz> Date: Tue, 24 Oct 2006 01:26:21 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: IETF SIP List Subject: Re: [Sip] SIP SAML: Issue #5 - Replay Protection: SIP specific Fields in the SAML Assertion References: <45323D22.7090700@gmx.net> In-Reply-To: <45323D22.7090700@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 Hannes Tschofenig wrote: > > I agree with Jonathan's observation. We should define some new fields > that can be carried in the SAML assertion and address this threat. agreed. We need to be careful about how retargeting and forking might affect what sort of info we include in the SAML Assertion, yes? =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 05:23:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcISB-0000Cm-CI; Tue, 24 Oct 2006 05:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcIS9-0000Cf-Vu for sip@ietf.org; Tue, 24 Oct 2006 05:20:09 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcIS3-0004t9-FC for sip@ietf.org; Tue, 24 Oct 2006 05:20:09 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k9O9K2eV005275; Tue, 24 Oct 2006 11:20:02 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k9O9K1SN012456; Tue, 24 Oct 2006 11:20:01 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 11:20: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] SIP SAML: Issue #5 - Replay Protection: SIP specific Fieldsin the SAML Assertion Date: Tue, 24 Oct 2006 11:20:00 +0200 Message-ID: In-Reply-To: <453DCE2D.4020806@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP SAML: Issue #5 - Replay Protection: SIP specific Fieldsin the SAML Assertion Thread-Index: Acb3SPUUsv2SxFLORHmqMISY01lkxAAAKbKw From: "Tschofenig, Hannes" To: "Jeff Hodges" , "IETF SIP List" X-OriginalArrivalTime: 24 Oct 2006 09:20:01.0457 (UTC) FILETIME=[9536B210:01C6F74D] X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Jeff,=20 that's a good point. In issue#3 Jonathan complainted about the = restrictions we put into the conditions element (see = http://www.tschofenig.priv.at:8080/saml-sip/issue6) and he points to the = problems in context with retargeting and forking.=20 In issue#5 (see http://www.tschofenig.priv.at:8080/saml-sip/issue5), = however, Jonathan wants to put some additional fields into the SAML = assertion to prevent replay attacks.=20 I think we can only put parameters like From, Contact, Date and Call-ID = in there to avoid jumping into other problems. With the generalized = approach used in SIP Payment there are more options, such as using the = holder-of-the-key assertion. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Jeff Hodges [mailto:Jeff.Hodges@neustar.biz]=20 > Gesendet: Dienstag, 24. Oktober 2006 10:26 > An: IETF SIP List > Betreff: Re: [Sip] SIP SAML: Issue #5 - Replay Protection:=20 > SIP specific Fieldsin the SAML Assertion >=20 > Hannes Tschofenig wrote: > > > > I agree with Jonathan's observation. We should define some=20 > new fields > > that can be carried in the SAML assertion and address this threat. >=20 > agreed. >=20 > We need to be careful about how retargeting and forking might=20 > affect what sort=20 > of info we include in the SAML Assertion, yes? >=20 > =3DJeffH >=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 >=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 Oct 24 09:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMBv-0006LW-22; Tue, 24 Oct 2006 09:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMBt-0006LP-J2 for sip@ietf.org; Tue, 24 Oct 2006 09:19:37 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMBl-0000hl-Sa for sip@ietf.org; Tue, 24 Oct 2006 09:19:37 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9ODJP8H005047; Tue, 24 Oct 2006 08:19:25 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Oct 2006 08:19:25 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Oct 2006 15:19:23 +0200 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] RE: I-D ACTION:draft-drage-sip-essential-correction-00.txt Date: Tue, 24 Oct 2006 15:19:19 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918065EA2B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: I-D ACTION:draft-drage-sip-essential-correction-00.txt Thread-Index: Acb3Pe4jVGr7DOq+T32Hkkes1MMT6gAL7j2A From: "Drage, Keith \(Keith\)" To: "Elwell, John" , "SIP" X-OriginalArrivalTime: 24 Oct 2006 13:19:23.0126 (UTC) FILETIME=[056F7960:01C6F76F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 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 the question. This was drafted to beat the deadline so some of the text may require clarification.=20 Taking the core SIP spec as an example (although the document applies to core SIP and all extensions), we do not want to get into a process of revising RFC 3261 itself. That will involve us in a considerable amount of work that should be devoted either to new work, or to getting RFC 3261 to draft standard. The idea is to get the main technical corrections into a single document that can be read in conjunction with RFC 3261, and to give these corrections standards track RFC status so that: - everyone can find them; - everyone knows they have to implement them. With the exception of RFC 4320 and draft-ietf-sip-fork-loop-fix, this is not happening at the moment. This ideas in this draft have been discussed amond the SIP chairs and the ADs and some of our lead authors. We haven't come up with a better way of doing it. Unless anyone has a better idea then the idea would be to implement it after IETF#67. I can think of at least two issues that should be addressed immediately and I am sure that other people have a list of things that meet the criteria.=20 Once we agree this is what we are doing, I will put out a call to collect things that should be addressed urgently.=20 I will be seeking people to write those up. This activity will not preclude people addressing their own corrections within the same process. Regard it more as a starter. Regards Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 24 October 2006 08:26 > To: Drage, Keith (Keith); SIP > Subject: [Sip] RE: I-D=20 > ACTION:draft-drage-sip-essential-correction-00.txt >=20 > Keith, >=20 > In section 3 it states: > "At an appropriate period time, an editor working on behalf=20 > of the SIP working group will compile all changes that have=20 > successfully completed working group last call into a=20 > internet draft, along with the contents of all previous=20 > documents that update the SIP RFC requiring correction. > The internet draft will be submitted to IESG as a proposed=20 > standards track RFC for approval for publication, without any=20 > further working group last call." >=20 > Just to be clear, this I-D is a compilation of changes, not a=20 > copy of the original RFC with changes applied? Therefore this=20 > I-D will update the original RFC, and not obsolete it? Other=20 > documents that reference the original RFC can still continue to do so? >=20 > Is there a plan to trawl all previously reported bugs to see=20 > which are eligible for dealing with in this way? >=20 > Would you consider my draft-elwell-sipping-update-pai would=20 > qualify for this process? I guess not, as it concerns an=20 > informational RFC that is the responsibility of SIPPING. >=20 > John >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: 18 October 2006 20:50 > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-drage-sip-essential-correction-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > >=20 > > Title : A Process for Handling Essential=20 > > Corrections to the Session Initiation Protocol (SIP) > > Author(s) : K. Drage > > Filename : draft-drage-sip-essential-correction-00.txt > > Pages : 11 > > Date : 2006-10-18 > > =09 > > The Session Initial Protocol (SIP) defined in RFC 3261=20 > and a large > > number of extensions forms a considerable body of work, which=20 > > through > > sheer size has a number of errors that require correction. This > > document explains the process for managing essential=20 > corrections to > > SIP. > >=20 > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-drage-sip-essential- > > correction-00.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then "get=20 > > draft-drage-sip-essential-correction-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-drage-sip-essential-correction-00.txt". > > =09 > > 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=20 > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=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 Oct 24 09:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMGL-000414-Tg; Tue, 24 Oct 2006 09:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcMGK-0003tE-A5 for sip@ietf.org; Tue, 24 Oct 2006 09:24:12 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcMGH-000203-WB for sip@ietf.org; Tue, 24 Oct 2006 09:24:12 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id k9ODN88B014119 for ; Tue, 24 Oct 2006 08:24:09 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Oct 2006 08:23:54 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Oct 2006 15:23:14 +0200 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 Date: Tue, 24 Oct 2006 15:23:11 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918065EA37@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for views on draft-drage-sip-essential-correction-00.txt Thread-Index: Acb3b42jxHtFHebmRGakvXbI27X4Ag== From: "Drage, Keith \(Keith\)" To: "SIP" X-OriginalArrivalTime: 24 Oct 2006 13:23:14.0720 (UTC) FILETIME=[8F79EA00:01C6F76F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] Request for views on draft-drage-sip-essential-correction-00.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 have recently submitted http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction -00.txt The idea behind this draft, is to put some management into getting real bugfixes: - into one place where people can find it - give it standards track RFC status so that people know they have to implement it. If people not already consulted have views on this process, then please let them be known. The idea would be to start this process (taking into account any input from the WG) after the next IETF meeting. 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 Tue Oct 24 12:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcP3d-0007ED-Ib; Tue, 24 Oct 2006 12:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcP3c-00079I-Gn for sip@ietf.org; Tue, 24 Oct 2006 12:23:16 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcP3X-0005CW-JP for sip@ietf.org; Tue, 24 Oct 2006 12:23:16 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9OFQbcR010659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Oct 2006 10:26:38 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP List Message-Id: <266D32BC-7B30-4BB5-A22E-0B9A6628F2E4@softarmor.com> From: Dean Willis Date: Tue, 24 Oct 2006 11:23:06 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 Subject: [Sip] Revsied SIP agenda for IETF 67 X-BeenThere: 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="===============1441832950==" Errors-To: sip-bounces@ietf.org --===============1441832950== Content-Type: multipart/alternative; boundary=Apple-Mail-2-863676773 --Apple-Mail-2-863676773 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Ok kids, here's another try at organizing the playtime of our distinguished scholars and schoolyard bullies. Note that we've proposed not to discuss the Consent Framework and related drafts. It's been suggested that this formidable task justifies an interim meeting in its own right. How do you people feel about that? The Friday agenda still seems a bit crowded. My finely calibrated timing sense (for you comic book fans, assume I was bitten by a radioactive stopwatch in my infancy) tells me that we won't actually make it through this agenda in the time allotted. Maybe they won't throw us out immediately at 11:30, but it would help if we can stay on topic. You may also note that we've added the SIPS guidelines work to the main agenda rather than having a separate breakout on Security. Furthermore, we now have Jonathan Rosenberg leading a discussion about Route Construction, rather than the Route Construction draft leading a conversation about Jonathan Rosenberg. This latter discussion (about Jonathan) will be relegated to the bar where instead of being presented by a draft document it can be properly presented with a draft beer and where the concomitant choruses of "hip, hip, hoorah" will be mistaken by the other patrons as having something to do with football. Anyhow, here's the agenda. I apologize for the HTML to those of you lacking the ability to read it, but I'm much too lazy to reformat it as plain text unless somebody tells me they really need it in that format. Draft Agenda, SIP at IETF 67 Session 1: Thursday 1300-1500 Grand Ballroom C Time Topic Discussion leaders Reading List 1300 Agenda Bash and Status Chairs this document 1305 Location Conveyance James Polk Brian Rosen draft-ietf-sip-location-conveyance-05 1325 Connected Identity John Elwell draft-ietf-sip-connected-identity-02 1400 Identity Coexistence Jonathan Rosenberg draft-rosenberg-sip-identity-coexistence-01 1415 GRUU and Supporting Drafts Jonathan Rosenberg draft-ietf-sip-gruu-11 draft-rosenberg-sip-ua-loose-route-00 Session 2: Friday 0900-1130 Grand Ballroom C Time Topic Discussion leaders Reading List 0900 Agenda Bash Chairs This Document 0905 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-05 0935 Domain Certs and Connection Reuse Vijay Gurbani draft-gurbani-sip-domain-certs-03 draft-ietf-sip-connect-reuse-07 0955 Outbound Discovery and Mid-Dialog requests Jonathan Rosenberg draft-rosenberg-sip-outbound-discovery-mid-dialog-00 1010 SIPS Guidelines Francois Audet draft-audet-sip-sips-guidelines-04 1040 Diagnostic Responses Scott Lawrence Vijay Gurbani draft-ietf-sip-hop-limit-diagnostics-04 draft-gurbani-sip-large-udp-response-00 1100 UA Profile Delivery Dan Petrie draft-ietf-sip-xcap-config-00 1115 Route Construction Jonathan Rosenberg draft-rosenberg-sip-route-construct-02 --Apple-Mail-2-863676773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1


Ok kids, here's another try = at organizing the playtime of our distinguished scholars and schoolyard = bullies.

Note = that we've proposed not to discuss the Consent Framework and related = drafts. It's been suggested that this formidable task justifies an = interim meeting in its own right. How do you people feel about = that?

The = Friday agenda still seems a bit crowded. My finely calibrated timing = sense (for you comic book fans, assume I was bitten by a radioactive = stopwatch in my infancy) tells me that we won't actually make it through = this agenda in the time allotted. Maybe they won't throw us out = immediately at 11:30, but it would help if we can stay on = topic.

You may also note that we've added the SIPS = guidelines work to the main agenda rather than having a separate = breakout on Security. Furthermore, we now have Jonathan Rosenberg = leading a discussion about Route Construction, rather than the Route = Construction draft leading a conversation about Jonathan Rosenberg. This = latter discussion (about Jonathan) will be relegated to the bar where = instead of being presented by a draft document=A0it can be = properly presented with a draft beer and where the=A0concomitant = choruses of "hip, hip, hoorah" will be mistaken by the other patrons as = having something to do with football.

Anyhow, here's the agenda. = I apologize for the HTML to those of you lacking the ability to read it, = but I'm much too lazy to reformat it as plain text unless somebody tells = me they really need it in that format.




Draft Agenda, SIP at IETF 67



Session 1: Thursday 1300-1500 Grand Ballroom = C


<= /TR><= /TR>
Time
Topic
Discussion leaders
Reading = List
1300
Agenda Bash and Status
Chairs
this = document
1305
Location Conveyance
James Polk
Brian = Rosen
1325
Connected = Identity
John Elwell
1400
Identity = Coexistence
Jonathan Rosenberg
=
1415
GRUU and Supporting Drafts
Jonathan = Rosenberg


Session 2: = Friday 0900-1130 Grand Ballroom C


0935
= =
Time
Topic
Discussion leaders
Reading = List
0900
Agenda Bash
Chairs
This Document
0905
Outbound
Rohan Mahy
Cullen Jennings
Domain Certs and=A0
Connection = Reuse
Vijay Gurbani
0955
Outbound Discovery=A0
and Mid-Dialog = requests
Jonathan Rosenberg
1010
SIPS Guidelines
Francois Audet
1040
Diagnostic = Responses
Scott Lawrence
Vijay = Gurbani
draft-gurbani-sip-large-udp-response-00
1100
UA Profile = Delivery
Dan Petrie
1115
Route Construction
Jonathan Rosenberg


= --Apple-Mail-2-863676773-- --===============1441832950== 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 --===============1441832950==-- From sip-bounces@ietf.org Tue Oct 24 14:47:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRGK-0001Ls-N9; Tue, 24 Oct 2006 14:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRGJ-0001IY-7q; Tue, 24 Oct 2006 14:44:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRGG-00010b-Mz; Tue, 24 Oct 2006 14:44:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Oct 2006 11:44:28 -0700 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 k9OIiSdc032029; Tue, 24 Oct 2006 14:44:28 -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 k9OIiRDa018454; Tue, 24 Oct 2006 14:44:28 -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, 24 Oct 2006 14:44:21 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 14:44:21 -0400 Message-ID: <453E5F04.5010709@cisco.com> Date: Tue, 24 Oct 2006 14:44:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt References: <004b01c6f411$2b1585d0$0601a8c0@BEMBUSTER> In-Reply-To: <004b01c6f411$2b1585d0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 18:44:21.0161 (UTC) FILETIME=[6B2B8190:01C6F79C] DKIM-Signature: a=rsa-sha1; q=dns; l=8828; t=1161715468; x=1162579468; 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]=20I-D=20ACTION=3Adraft-ietf-sip-location-conveyance-05.txt |To:sip@ietf.org; X=v=3Dcisco.com=3B=20h=3D9GvbvL6z3998Z3Pi6ykfATxsbVs=3D; b=RXhDcUB/1hoPEFI/M83jbBh0UcFpsvVeKOsuGrmIusZWUbjy42cU8O1TtbP53Qo6+TtuiOSI Wwm9KU6IqQx6ndmlgqdIK043OJSkU8LIXOdqVYAQyIUeSvbol2aO292Q; 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: 97c820c82c68af374c4e382a80dc5017 Cc: geopriv@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 this draft is much improved. While there are some things to clean up, I think it now reads well and the form/structure seem close to done. I agree with Jeroen about the syntax. Rather than explicitly including <> in the syntax you could simply allow name-addr / addr-spec as many headers do. This allows either form and display names as well, even if they don't have a lot of use here. Allowing both forms would probably save a lot of grief. Regarding header parameters in the syntax: there might already be value in a parameter to indicate preference among multiple geolocations, or to identify the party that supplied the header. Multiple locations are at SHOULD NOT strength, but I bet they will occur. It would be helpful to have a way to specify some context or reason for the presence of one. Another possibility is q-values. I have a number of other comments: In section 3.2: There MUST NOT be more than one cid-url pointing to the same location message body (part) in a SIP message. Hmm. Its conceivable that the UA might want to include this, and then a proxy might want to add another geolocation header that refers to the same body in order to add its own assertion that this is the proper location. This would make more sense if there were parameters indicating that one was from the UA and another was from a proxy. Its also possible that a UAC might want to reference the location for purpose of location-conveyance and for some entirely unrelated purpose. I admit this is a stretch, but I see no reason to forbid it. In section 3.5: A UAC MUST NOT include this option tag in a Proxy-Require header, due to the fact that the UAC is not likely to understand the topology of the infrastructure, and therefore does not understand which proxy will do the location-based routing function. In the above, SHOULD NOT seems more appropriate. While a UAC may not be likely to understand the topology, in some cases it might. When using location-by-value, what Content-Disposition is to be used? The default is "render", which may not be appropriate. Perhaps "attachment" would be suitable. Also, it should probably contain a "handling=optional" in case the recipient doesn't support it. In example 4.2 there is no Content-Id header matching the CID URI in the Geolocation header. When using S/MIME to protect a location-by-value, should the Content-Id referenced by the Geolocation header be on the application/pkcs7-mime body, or on the enclosed application/pidf+xml body? Are there variations on how this can be done? (For instance if the intent is to use the S/MIME body to protect both the location and the sdp.) In 5.1: ... A location body sent without a Geolocation header MUST NOT occur. This seems overly restrictive. It precludes the use of location bodies for purposes entirely unrelated to Geolocation and location conveyance as defined in this draft. The whole point of CID is so that headers can point to body parts and add context about how they are to be used. I think this draft should be silent on this point, or simply mention that a location body that is not referenced by a CID URI in a Geolocation header has no relevance to location conveyance as defined in this draft. In 5.2: If the geolocation option tag is present in the Supported header of a request, the UAS will look to the Geolocation header to see if location has been conveyed ... Is there any reason why the UAS shouldn't interpret Geolocation even when Supported: geolocation is not present? In fact, the UAS needs to do this when the UAC didn't support, but a proxy added location information. A Require header with the geolocation option tag indicates that the UAC requests the UAS' location. Really? Normally a Require would only mean that the UAS is required to *understand* geolocation. But I guess there is some precedent for making additional demands. I presume this does not mean that the UAS must fail the request if it can't return its location - rather I think it at most means that the UAS should attempt to return its location if it can. (It might not know its location.) That's all for now, Paul Jeroen van Bemmel wrote: > I think this draft has much improved. However, there remains an issue > with the ABNF: > > Geolocation = "Geolocation" HCOLON (locationURI *(COMMA > locationURI)) > locationURI = sip-URI / sips-URI / pres-URI / cid-URI > / absoluteURI > cidURI = "cid:" content-id > content-id = addr-spec ; URL encoding of RFC3261 addr-spec > I would suggest to use '<' '>' around the URI, and allow for generic > header parameters. This is inline with the second example used in > section 4.2: > > Geolocation = "Geolocation" HCOLON (locationValue *(COMMA > locationValue))locationValue = LAQUOT > locationURI RAQUOT *(SEMI generic-param)locationURI = sip-URI / > sips-URI / pres-URI / cid-URI > / absoluteURI > cidURI = "cid:" content-id > content-id = addr-spec ; URL encoding of RFC3261 addr-spec > Second comment: section 3.5 still contains the phrase "Appearance of the > option tag in the Require header is a request for location to be > conveyed." Such semantics are not common for Require > > Regards, > Jeroen > > > Internet-Drafts@ietf.org wrote: >>> 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-05.txt >>> Pages : 26 >>> Date : 2006-10-19 >>> >>> 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-05.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-05.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-05.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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 24 15:31:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRwQ-0001Vp-6I; Tue, 24 Oct 2006 15:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRwO-0001TK-Fz for sip@ietf.org; Tue, 24 Oct 2006 15:28:00 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRwK-00084x-18 for sip@ietf.org; Tue, 24 Oct 2006 15:28:00 -0400 Received: (qmail 25723 invoked by uid 0); 24 Oct 2006 19:28:43 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 Oct 2006 19:28:43 -0000 Message-ID: <000601c6f7a2$6ecd2aa0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , References: <004b01c6f411$2b1585d0$0601a8c0@BEMBUSTER> <453E5F04.5010709@cisco.com> Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt Date: Tue, 24 Oct 2006 21:27:21 +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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: geopriv@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 agree with Jeroen about the syntax. Rather than explicitly including > <> in the syntax you could simply allow name-addr / addr-spec as many > headers do. This allows either form and display names as well, even if > they don't have a lot of use here. Allowing both forms would probably > save a lot of grief. I simply followed the syntax of headers like Call-Info and Error-Info. A DisplayName could have a use as a name for the location ("Home"), it's not a bad idea to include something for presentation to humans. Would typically serve as a tag one would display on a generated map, for example 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 Tue Oct 24 18:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUjW-00014T-P8; Tue, 24 Oct 2006 18:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUjV-00013V-D5 for sip@ietf.org; Tue, 24 Oct 2006 18:26:53 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUjS-0007ar-Uv for sip@ietf.org; Tue, 24 Oct 2006 18:26:53 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1458527ugd for ; Tue, 24 Oct 2006 15:26:49 -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=CdaYK7OBCjj3+hGiORBi42IsoVDIsVqPJxMLOQG1dNWiBBz8K1cuL/M9XdWvJloFLQrhrzh4cp3QyLzVeiLe8xF9e4SibbFTit8wep167GnFiizJ1A0jjyfrD2ixO2z3uW31Dr69wbl7AAOo+lzBMcFJzDctu8IuMQII2syCu+Y= Received: by 10.78.157.8 with SMTP id f8mr10051111hue; Tue, 24 Oct 2006 15:26:49 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Tue, 24 Oct 2006 15:26:49 -0700 (PDT) Message-ID: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> Date: Tue, 24 Oct 2006 15:26:49 -0700 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <452FC0B7.6030007@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <452FC0B7.6030007@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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, I have read this draft and I think it is a terrible idea in SIP/2.0 to send a UA an incoming request with a Route header. If we were working on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea to consider as baseline behavior, but I think this is too major of a change from the current spec and state of implementation. Lets analyze the requirements described in the document. The unkown gruu, limited-use gruu, subaddressing, and service invocation requirements can all be met just by restoring the grid parameter to its rightful place in GRUU. The emergency services requirement is a tautology; if a proxy wants to rewrite the Request-URI from an SOS URN, don't do that, insert a loose-route instead; no additional mechanism or specification is necessary. The freephone requirement deals with mixed SIP and PSTN networks, where the existing History-Info (or dare I say Diversion) mechanism is perfectly adequate and more likely to be implemented in this environment. The alias requirement can be addresses in a variety of ways including configuration, or simply restoring the To header to usefulness. My conclusion is that this mechanism does not solve any requirements we are not already addressing. (If we were starting from scratch, we might do things differently). As for the implications of handling loose-routing on the UA, I do not believe the expected behavior is easily containable. The only entities that should receive requests with additional Route headers are proxy servers. Embedding a proxy server in/on a UA then requires the UA to implement TLS, strict route fix ups, loop detection, and a host of other things. I don't think we want to go there. The alternative is for us to break the rules and define a "sort of a proxy" role. I expect picking apart what parts of RFC3261 need to be implemented as a proxy would be a nightmare. I can also imagine the impact on the outbound draft if each outbound UA needs to route through an embeded edge proxy. How will the first "real" edge proxy decide if outbound processing has been done correctly? The concept of logical roles such as proxy, registrar, identity server, etc. is already confusing to many implementors. If we start redefining or breaking the rules which describe existing roles, I believe we are going to have a real mess on our hands. thanks, -rohan On 10/13/06, Jonathan Rosenberg wrote: > I've submitted a new I-D which describes this concept of UA loose > routing that we've been discussing on the list. This fell out of the > GRUU discussions as an alternative solution for grid. As the draft > explains, the mechanism also solves many other problems, like > sub-addressing, limited use adresses, 8xx number usage, and is even > required for proper 911/emergency services operation with ecrit. > > Until the draft appears in the archives, you can pick it up at: > http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt > > 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 From sip-bounces@ietf.org Tue Oct 24 18:38:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUsG-0007B4-9e; Tue, 24 Oct 2006 18:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUsE-0007Az-Ru for sip@ietf.org; Tue, 24 Oct 2006 18:35:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUsC-0002W2-Fr for sip@ietf.org; Tue, 24 Oct 2006 18:35:54 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1460531ugd for ; Tue, 24 Oct 2006 15:35:51 -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=B+gciGpHGd9x129Jtw7a7lJmKrPKy0SFm3847HP1R9mjHen+2C64X/75DnTx3f6Le+g2crxxex27/sW6/Nb4lV+9Cb0ggWGGjncODdpctixfnq2vsNrsC/Sjl7CkoNkVTbXgC9HY+Mq1bNzTyauH1yp1nIuaL0e5LZ9YfNZL+hg= Received: by 10.78.188.19 with SMTP id l19mr10000816huf; Tue, 24 Oct 2006 15:35:51 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Tue, 24 Oct 2006 15:35:50 -0700 (PDT) Message-ID: <953beacc0610241535v4299885di72ea84260d671856@mail.gmail.com> Date: Tue, 24 Oct 2006 15:35:50 -0700 From: "Rohan Mahy" To: "Dean Willis" Subject: Re: [Sip] GRUU and Grid alternative In-Reply-To: <4529E66D.9070307@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> <452692FA.5000709@cisco.com> <4529E66D.9070307@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List , Paul Kyzivat , Juha Heinanen , Brian Stucker X-BeenThere: sip@ietf.org X-Mailman-Version: 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 a better idea. Either do the speedial translation directly in the UA, or have your proxy send back a 3xx with the correct URI: INVITE sip:7@myspeedial.example.net To: "#7" SIP/2.0 300 Redirect Contact: "Brittney Spears" INVITE sip:brittney@spears.tv To: "Brittney Spears" Now Brittney can use the Identity header to assure you that its her when she answers. thanks, -rohan On 10/8/06, Dean Willis wrote: > Paul Kyzivat wrote: > > Dean, > > > > I pretty much agree with you. > > > > Regarding response identity and your example: > > > > you called sip:7@myspeedial.example.net, and your server retargeted to > > sip:brittney@spears.tv. So you are suggesting that your server should > > notify you this happened, so that when you received response identity > > you will not be surprised. > > > > Instead of this, how about having the proxy remain on the path and > > insert a response identity for 7@myspeedial.example.net at least in > > requests/responses that carry some other identity? > > Well, that sort of works, except that the call might be retargeted again > by brittney's server, and I want to know about that too. > > > Regarding not wanting Brittney to know she's #7: what will you do about > > the To header? > > Populate it with "Anonymous" like I always do with the useless To: > header? I'm starting to think that putting anything meaningful in To is > a recipe for heartburn. > > -- > 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 Oct 24 19:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVGK-0007xS-Rs; Tue, 24 Oct 2006 19:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVGH-0007wb-OO for sip@ietf.org; Tue, 24 Oct 2006 19:00:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVGF-0000kc-VB for sip@ietf.org; Tue, 24 Oct 2006 19:00:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 19:00:42 -0400 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 k9ON0hxE018616; Tue, 24 Oct 2006 19:00:43 -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 k9ON0cYr027483; Tue, 24 Oct 2006 19:00:43 -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, 24 Oct 2006 19:00:39 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 19:00:36 -0400 Message-ID: <453E9B13.1010209@cisco.com> Date: Tue, 24 Oct 2006 19:00:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Rohan Mahy Subject: 3xx for proxy expansion of dial strings. (Was: Re: [Sip] GRUU and Grid alternative) References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> <452692FA.5000709@cisco.com> <4529E66D.9070307@softarmor.com> <953beacc0610241535v4299885di72ea84260d671856@mail.gmail.com> In-Reply-To: <953beacc0610241535v4299885di72ea84260d671856@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2006 23:00:36.0573 (UTC) FILETIME=[37A130D0:01C6F7C0] DKIM-Signature: a=rsa-sha1; q=dns; l=3390; t=1161730843; x=1162594843; 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:3xx=20for=20proxy=20expansion=20of=20dial=20strings.=20(Was=3A=20Re=3A=2 0[Sip]=20GRUU=20and=0A=20Grid=20alternative) |To:Rohan=20Mahy=20; X=v=3Dcisco.com=3B=20h=3DTLpxW8F9s9WSJlHLPpGa4+UuOGQ=3D; b=FqDFJhgnpMvJlO8/Lvs82V8DoqJ3NNlxuBLOrFL9eZWO/un9kXjw9fuRRRiVf40KAkmC0HH5 Loy/YG9hCYDx7MXyB5NYzp0l9DvMKhR1UxvLTrG2gKQ5ZjcIfNSOYUj9; 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: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Juha Heinanen , Brian Stucker , 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 Rohan, Regardless of the GRUU and Grid issues, I agree that 3xx is an attractive solution to dialstring expansion by a proxy. But I think there is a bit of work to do to make that fully workable. That is to figure out and fully specify how the 3xx response can specify that the To header should be replaced as well as the R-URI when recursing on the 3xx. (This of course only works for the UAC - when a proxy recurses it can't do this. If there was a way to indicate it, then a proxy could use that as an indication that it ought to pass the response back rather than recursing itself.) I think we have discussed this before. One suggestion was to embed a To header in the returned Contact. I was never very wild about that, but its a possibility. Another is to define a special 3xx code specifically for this purpose. And maybe there are other possibilities. An advantage of this is that it ensures that the dial strings, which are caller specific, never make it to the callee. There are cases where it makes sense for the callee to interpret the To header, or maybe H-I, but it doesn't work well if there are dial strings there. (Hmm. I think that means that when this is indicated with the 3xx, the new request should start over with a fresh H-I header too, rather than recording the history of this redirection.) Paul Rohan Mahy wrote: > Hi, > > I have a better idea. Either do the speedial translation directly in > the UA, or have your proxy send back a 3xx with the correct URI: > > INVITE sip:7@myspeedial.example.net > To: "#7" > > SIP/2.0 300 Redirect > Contact: "Brittney Spears" > > INVITE sip:brittney@spears.tv > To: "Brittney Spears" > > Now Brittney can use the Identity header to assure you that its her > when she answers. > > thanks, > -rohan > > > > On 10/8/06, Dean Willis wrote: >> Paul Kyzivat wrote: >> > Dean, >> > >> > I pretty much agree with you. >> > >> > Regarding response identity and your example: >> > >> > you called sip:7@myspeedial.example.net, and your server retargeted to >> > sip:brittney@spears.tv. So you are suggesting that your server should >> > notify you this happened, so that when you received response identity >> > you will not be surprised. >> > >> > Instead of this, how about having the proxy remain on the path and >> > insert a response identity for 7@myspeedial.example.net at least in >> > requests/responses that carry some other identity? >> >> Well, that sort of works, except that the call might be retargeted again >> by brittney's server, and I want to know about that too. >> >> > Regarding not wanting Brittney to know she's #7: what will you do about >> > the To header? >> >> Populate it with "Anonymous" like I always do with the useless To: >> header? I'm starting to think that putting anything meaningful in To is >> a recipe for heartburn. >> >> -- >> 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 Oct 24 19:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVIA-0001O6-NJ; Tue, 24 Oct 2006 19:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVI8-0001Ng-H2 for sip@ietf.org; Tue, 24 Oct 2006 19:02:40 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVI4-00023t-1C for sip@ietf.org; Tue, 24 Oct 2006 19:02:40 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9ON2ZWn012942 for ; Tue, 24 Oct 2006 18:02:35 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Oct 2006 18:02:35 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 25 Oct 2006 01:02:33 +0200 Subject: RE: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Oct 2006 01:02:33 +0200 Content-class: urn:content-classes:message Message-ID: <5D1A7985295922448D5550C94DE2918065EC07@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 Thread-Index: Acb3BuE8/yFN+ct4RIKvN26/63HjjAAhyG6Q From: "Drage, Keith \(Keith\)" To: "sip" X-OriginalArrivalTime: 24 Oct 2006 23:02:33.0945 (UTC) FILETIME=[7D96BC90:01C6F7C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Now we have finally got this document, I want you all to wind yourself back the discussions we were having three months ago. Does this update reflect what you think you were discussing. If so say so on the list. If it doesn't then also say so on the list. This has an agenda slot in IETF#67. I want to see the content of that agenda slot reflecting issues of current concern to the WG. This work is meant to be high priority. It should be finished. It has been in WGLC for a long time. Let's work to get it out of the door. Regards Keith > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: 24 October 2006 01:49 > To: sip > Cc: Rohan Mahy > Subject: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 >=20 > Hi Folks, >=20 > Yesterday I did an extremely belated, but very detailed=20 > update to outbound. I believe that I have incorporated all=20 > the changes we discussed at the Montreal meeting and the=20 > consenus reached on the mailing list regarding STUN. I also=20 > incorporated a new short section explaining how STUN=20 > keepalives would work with SigComp, as well as many=20 > clarifications from private comments. >=20 > There are a few new changes which are listed as potential=20 > issues at the bottom of this email. I introduced a new=20 > status code instead of using 480 or 410, I added a new timer=20 > to determine when a flow is stable to make sure that the=20 > avalanche restart prevention really works, and I changed the=20 > text about which nodes have to add a Path header or store the=20 > previous hop flow information. Please especially read=20 > through these. If you like these changes please send me a=20 > quick email to that effect. If not please send proposed changes. >=20 > Until the draft appears in the archives, you can get it here: >=20 > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si > p-outbound-05.txt > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si > p-outbound-05.html >=20 > thanks, > -rohan >=20 > Changes from outbound-04 to -05: >=20 > STUN-related changes: > Moved STUN Keepalive description to a separate section (section 8). > Referenced this section from within the relevant sections in=20 > the rest of the document. >=20 > Added language clarifying that UA MUST NOT send STUN without=20 > an explicit indication the server supports STUN, and that a=20 > UA MUST stop sending STUN if it appears the server does not=20 > support it (ex:initial STUN request fails). >=20 > Defined a 'sip-stun' option tag. UAs can optionally probe=20 > servers for it with OPTIONS. Clarified that UAs SHOULD NOT=20 > put this in a Proxy-Require. Explain that the first-hop MUST=20 > support this option-tag. >=20 > Clarify that STUN done in conjuction with SIP over TLS is on=20 > the "inside" of the TLS record-layer. >=20 > Added a new section explaining the how STUN keepalives are=20 > used with Sigcomp-compressed SIP messages. STUN is "outside"=20 > the compression layer for UDP, but wrapped inside the=20 > well-known shim header for TCP-based transports. >=20 > Non-STUN changes: > Change a MUST to SHOULD based on consensus at last meeting. =20 > The UAC SHOULD register a flow for each member of the=20 > outbound-proxy-set. >=20 > Added comment about reregistration typically happening over=20 > same flow as original registration. >=20 > Consistent with my email proposal about Slides 9 and 10 from=20 > IETF66, I added text about the 'ob' parameter which is used=20 > in Path header field URIs to make sure that the previous=20 > proxy that added a Path understood outbound processing. The=20 > registrar doesn't include Supported: outbound unless it could=20 > actually do outbound processing (ex: any Path headers have to=20 > have the 'ob' parameter). >=20 > Added some text describing what a registration means when=20 > there is an instance-id, but no reg-id. This is necessary to=20 > make GRUU work for example. >=20 > Reworded registrar and proxy in some places (introduce the=20 > term "Authoritative Proxy"). Several folks pointed out that=20 > we were being sloppy with the proxy accepting register=20 > requests and the registrar forward requests. I think these=20 > are all fixed now. >=20 > ISSUE: > Changed 410 Gone to new response code 430 Flow Failed. Based=20 > on consensus at the last meeting, I was going to change this=20 > to 480 Temporarily Unavailable. Unfortunately this would not=20 > work. A phone that uses 480 today for the suggested purpose=20 > of saying "Do Not Disturb" would trigger the authoritative=20 > proxy to delete all the flows of that phone. Oops! I'm=20 > hoping this is fine with everyone. >=20 > ISSUE: > Clarified how to decide what a consecutive registration timer is. > Proposal in the draft is that a flow must be stable for some=20 > time (default 120 seconds) otherwise previous registration is=20 > not considered successful. Are folks OK with this? >=20 > ISSUE: > Loosened restrictions on always storing a complete Path=20 > vector back to the registrar/authoritative proxy if a=20 > previous hop in the path vector is reachable. This was one of=20 > the biggest problems with the draft. > Now it is pretty clear how you can build an archtiecture=20 > where the registrar is separate from the authoritative proxy,=20 > and also clear how you can visit several edge proxies, but=20 > not all of them have to be in the Path. Please read this=20 > wording carefully in Section 5.1 and Section 6. Is this OK? >=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 Oct 24 19:34:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVip-0006Hr-Dw; Tue, 24 Oct 2006 19:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVin-0006Hm-JV for sip@ietf.org; Tue, 24 Oct 2006 19:30:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVil-0001vG-1T for sip@ietf.org; Tue, 24 Oct 2006 19:30:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1469779ugd for ; Tue, 24 Oct 2006 16:30:10 -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=Z7nzLBAF/DdYf+DUgBL0nr9H92eQz287DorYRywmIHvNdugglwNWqd8gCKDtvg6oUZdcx+WCcuIPYSGoaKSDyUb4HY2Uu44aFHK/IsZdMn74uWXwIALEfx0dIExWyrPoIivtmZ/anUTmNlxjngzEYQ8j7YqTfsYyZGpXuwy7jz0= Received: by 10.78.201.15 with SMTP id y15mr10096821huf; Tue, 24 Oct 2006 16:30:09 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Tue, 24 Oct 2006 16:30:09 -0700 (PDT) Message-ID: <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> Date: Tue, 24 Oct 2006 16:30:09 -0700 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <453DA2F3.1070009@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453DA2F3.1070009@cisco.com> 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, I'm not especially thrilled with several of these changes. We had a set of requirements that were reviewed carefully and represented a cohesive set of functionality. I don't see why we are changing the requirements now. More comments inline. On 10/23/06, Jonathan Rosenberg wrote: > I've submitted an update to the GRUU spec. Until it appears in the > archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-sip-gruu-11.txt > > This document represents some very major changes from -10. A design team > has been working extensively over the last month or so, and this > represents the current output of that work. Besides being more or less a > rewrite, the changes include: > > * Top-down rewrite of the document. New introduction from > EKR. Normative text moved around to be clearer. Redundant stuff > removed. Sections combined. Removed arcane discussion on URI > properties. Removed the arcane UML model and replaced it with a more > intuitive diagram on relationships. I think these changes definitely improved readability. > * added "anonymous gruu", known as temporary gruu. A temporary GRUU is > assigned when you first register a contact, and an additional one is > created on each refresh. All of the ones accumulated over the > lifetime of the registration remain valid. Each of them obfuscate > the AOR and instance ID. Added a description of a stateless > algorithm for computing these. Lengthy discussion on the privacy > implications of using them. I just reviewed the extremely lengthy thread on GRUU privacy and have yet to see anything resembling consensus on which privacy or limited-user requirements we are trying to add here. Furthermore I expect that the mechanism provided could be abused by UAs that want a private per call for example, creating a lot of registration thrash, jeopardizing the avalanche restart prevention work in outbound. > * removed completely the grid concept and associated processing. The > plan is to instead use loose routing or an alternative like it which > would allow a UA to add params to an AOR or a GRUU and get them back > in a request it receives. We had a requirement in the GRUU draft to be able to manufacture a whole family of GRUU. Grid satisfied this requirement. I STRONGLY object to any attempt to make this functionality depend on an untried, substantially risky new mechanism. I will take this to a process appeal if necessary. > * changed name of 'gruu' URI parameter to 'gr'. This parameter can now > take a value, folding in the functionality of 'opaque'. Removed the > opaque parameter. I like this. > * removed SIPS related processing rules > > * introduced this concept of self-made GRUU, which was there before > but kind of vague. This is to address Robert's concern about always > having proxies in the loop. A self-made GRUU is one constructed by a > UA using its IP address or hostname as the domain part of a SIP > URI. I like this. > * added a check in an originating proxy to make sure that the GRUU in > the INVITE matches the identity of the requestor. THis prevents an > attack whereby a malicious user could cause mid-dialog requests sent > by their peer to be targeted to a DoS target. > > * softened requirements around record-routing for home proxies. The > final algorithm differs for the originating and terminating > sides. On originating, if the request has a GRUU in the contact the > home proxy record routes. On terminating, it record routes if the > URI in the request URI is bound to a contact that has a GRUU. Other > proxies in the domain can do what they want. Some guidance is given > on what a proxy would see if it does or doesnt record route. > > * added rules for tel URI handling > > * removed bit about registering different contacts to each AOR when a > UA has multiple AOR; will leave that to the UA loose route spec Again, I object to making this document depend on the UA loose routing spec. If you want to tone down the language, I propose something like this: "Note a User Agent with multiple AORs needs to insure that it can distinguish requests to each AOR. One way to insure this property is to use a unique Contact URI per AOR." thanks, -rohan > * added requirement that contact cannot be weakly equivalent to AOR; > this deals with the GRUU loop problem (where a UA registers its own > GRUU as a contact with the instance ID associated with the GRUU, > causing the GRUU to resolve to itself). Previously, this was solved > by prohibiting the contact from being a GRUU. However, there are > valid cases for this when registering a instance in one domain to > another domain. This new rule allows this. > > > * Further clarifications on outbound proxies and gruu interactions > > -- > 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 Oct 24 19:39:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVoG-0003Ey-9n; Tue, 24 Oct 2006 19:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcVoF-0003ED-9y for sip@ietf.org; Tue, 24 Oct 2006 19:35:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcVoD-0002v9-TY for sip@ietf.org; Tue, 24 Oct 2006 19:35:51 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1470629ugd for ; Tue, 24 Oct 2006 16:35:49 -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=guokQ0JicFwFVD3G5E1XuTadYVaLZRKuef0PLyn3acRzgcBTEXfyi2eRASk+YEM+D9c/za4jqYzogdvxWMRiMggEa4akpJEco30Rq9M1l8kuj9H290d5zi/7cIBkBU9CC2MNn07+XUAc/l9qxsR/aRdp/t1S+RMLip3Lj1s4p/c= Received: by 10.78.204.7 with SMTP id b7mr10154713hug; Tue, 24 Oct 2006 16:35:48 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Tue, 24 Oct 2006 16:35:48 -0700 (PDT) Message-ID: <953beacc0610241635o2b8cdc48q8d65f13ddf3ad2e@mail.gmail.com> Date: Tue, 24 Oct 2006 16:35:48 -0700 From: "Rohan Mahy" To: "Paul Kyzivat" Subject: Re: 3xx for proxy expansion of dial strings. (Was: Re: [Sip] GRUU and Grid alternative) In-Reply-To: <453E9B13.1010209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6FC4416DDE56C44DA0AEE67BC7CA437110C4CF06@zrc2hxm2.corp.nortel.com> <452529CE.1080104@cisco.com> <17701.27248.192068.881081@rautu.tutpro.com> <452687A9.9050403@softarmor.com> <452692FA.5000709@cisco.com> <4529E66D.9070307@softarmor.com> <953beacc0610241535v4299885di72ea84260d671856@mail.gmail.com> <453E9B13.1010209@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: IETF SIP List , Juha Heinanen , Brian Stucker , 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 Paul, For the record, I was converted to the position that it is OK to embed a To header in a Contact during debates with Jon and Cullen over Identity. thanks, -rohan On 10/24/06, Paul Kyzivat wrote: > Rohan, > > Regardless of the GRUU and Grid issues, I agree that 3xx is an > attractive solution to dialstring expansion by a proxy. > > But I think there is a bit of work to do to make that fully workable. > That is to figure out and fully specify how the 3xx response can specify > that the To header should be replaced as well as the R-URI when > recursing on the 3xx. (This of course only works for the UAC - when a > proxy recurses it can't do this. If there was a way to indicate it, then > a proxy could use that as an indication that it ought to pass the > response back rather than recursing itself.) > > I think we have discussed this before. One suggestion was to embed a To > header in the returned Contact. I was never very wild about that, but > its a possibility. Another is to define a special 3xx code specifically > for this purpose. And maybe there are other possibilities. > > An advantage of this is that it ensures that the dial strings, which are > caller specific, never make it to the callee. There are cases where it > makes sense for the callee to interpret the To header, or maybe H-I, but > it doesn't work well if there are dial strings there. > > (Hmm. I think that means that when this is indicated with the 3xx, the > new request should start over with a fresh H-I header too, rather than > recording the history of this redirection.) > > Paul > > Rohan Mahy wrote: > > Hi, > > > > I have a better idea. Either do the speedial translation directly in > > the UA, or have your proxy send back a 3xx with the correct URI: > > > > INVITE sip:7@myspeedial.example.net > > To: "#7" > > > > SIP/2.0 300 Redirect > > Contact: "Brittney Spears" > > > > INVITE sip:brittney@spears.tv > > To: "Brittney Spears" > > > > Now Brittney can use the Identity header to assure you that its her > > when she answers. > > > > thanks, > > -rohan > > > > > > > > On 10/8/06, Dean Willis wrote: > >> Paul Kyzivat wrote: > >> > Dean, > >> > > >> > I pretty much agree with you. > >> > > >> > Regarding response identity and your example: > >> > > >> > you called sip:7@myspeedial.example.net, and your server retargeted to > >> > sip:brittney@spears.tv. So you are suggesting that your server should > >> > notify you this happened, so that when you received response identity > >> > you will not be surprised. > >> > > >> > Instead of this, how about having the proxy remain on the path and > >> > insert a response identity for 7@myspeedial.example.net at least in > >> > requests/responses that carry some other identity? > >> > >> Well, that sort of works, except that the call might be retargeted again > >> by brittney's server, and I want to know about that too. > >> > >> > Regarding not wanting Brittney to know she's #7: what will you do about > >> > the To header? > >> > >> Populate it with "Anonymous" like I always do with the useless To: > >> header? I'm starting to think that putting anything meaningful in To is > >> a recipe for heartburn. > >> > >> -- > >> 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 Oct 24 20:06:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWF1-0005zt-Ai; Tue, 24 Oct 2006 20:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWF0-0005zm-4n for sip@ietf.org; Tue, 24 Oct 2006 20:03:30 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWEx-0000od-He for sip@ietf.org; Tue, 24 Oct 2006 20:03:30 -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 k9P03CN04393; Tue, 24 Oct 2006 20:03:12 -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: 3xx for proxy expansion of dial strings. (Was: Re: [Sip] GRUU and Grid alternative) Date: Tue, 24 Oct 2006 19:03:07 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371111BE46F@zrc2hxm2.corp.nortel.com> In-Reply-To: <953beacc0610241635o2b8cdc48q8d65f13ddf3ad2e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3xx for proxy expansion of dial strings. (Was: Re: [Sip] GRUU and Grid alternative) Thread-Index: Acb3xSWPWhDEarzyQQSb0lCSi+5N4gAA8S3g From: "Brian Stucker" To: "Rohan Mahy" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: IETF SIP List , Juha Heinanen , 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 Including a tag? You just know someone's going to do it. Regards, Brian=20 > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Tuesday, October 24, 2006 6:36 PM > To: Paul Kyzivat > Cc: Dean Willis; IETF SIP List; Juha Heinanen; Stucker, Brian=20 > (RICH1:AR00) > Subject: Re: 3xx for proxy expansion of dial strings. (Was:=20 > Re: [Sip] GRUU and Grid alternative) >=20 > Hi Paul, >=20 > For the record, I was converted to the position that it is OK=20 > to embed a To header in a Contact during debates with Jon and=20 > Cullen over Identity. >=20 > thanks, > -rohan >=20 > On 10/24/06, Paul Kyzivat wrote: > > Rohan, > > > > Regardless of the GRUU and Grid issues, I agree that 3xx is an=20 > > attractive solution to dialstring expansion by a proxy. > > > > But I think there is a bit of work to do to make that fully=20 > workable. > > That is to figure out and fully specify how the 3xx response can=20 > > specify that the To header should be replaced as well as the R-URI=20 > > when recursing on the 3xx. (This of course only works for the UAC -=20 > > when a proxy recurses it can't do this. If there was a way=20 > to indicate=20 > > it, then a proxy could use that as an indication that it=20 > ought to pass=20 > > the response back rather than recursing itself.) > > > > I think we have discussed this before. One suggestion was=20 > to embed a=20 > > To header in the returned Contact. I was never very wild=20 > about that,=20 > > but its a possibility. Another is to define a special 3xx code=20 > > specifically for this purpose. And maybe there are other=20 > possibilities. > > > > An advantage of this is that it ensures that the dial=20 > strings, which=20 > > are caller specific, never make it to the callee. There are cases=20 > > where it makes sense for the callee to interpret the To header, or=20 > > maybe H-I, but it doesn't work well if there are dial strings there. > > > > (Hmm. I think that means that when this is indicated with=20 > the 3xx, the=20 > > new request should start over with a fresh H-I header too,=20 > rather than=20 > > recording the history of this redirection.) > > > > Paul > > > > Rohan Mahy wrote: > > > Hi, > > > > > > I have a better idea. Either do the speedial translation=20 > directly=20 > > > in the UA, or have your proxy send back a 3xx with the=20 > correct URI: > > > > > > INVITE sip:7@myspeedial.example.net > > > To: "#7" > > > > > > SIP/2.0 300 Redirect > > > Contact: "Brittney Spears" > > > > > > INVITE sip:brittney@spears.tv > > > To: "Brittney Spears" > > > > > > Now Brittney can use the Identity header to assure you=20 > that its her=20 > > > when she answers. > > > > > > thanks, > > > -rohan > > > > > > > > > > > > On 10/8/06, Dean Willis wrote: > > >> Paul Kyzivat wrote: > > >> > Dean, > > >> > > > >> > I pretty much agree with you. > > >> > > > >> > Regarding response identity and your example: > > >> > > > >> > you called sip:7@myspeedial.example.net, and your server=20 > > >> > retargeted to sip:brittney@spears.tv. So you are=20 > suggesting that=20 > > >> > your server should notify you this happened, so that when you=20 > > >> > received response identity you will not be surprised. > > >> > > > >> > Instead of this, how about having the proxy remain on the path=20 > > >> > and insert a response identity for 7@myspeedial.example.net at=20 > > >> > least in requests/responses that carry some other identity? > > >> > > >> Well, that sort of works, except that the call might be=20 > retargeted again > > >> by brittney's server, and I want to know about that too. > > >> > > >> > Regarding not wanting Brittney to know she's #7: what=20 > will you do=20 > > >> > about the To header? > > >> > > >> Populate it with "Anonymous" like I always do with the=20 > useless To: > > >> header? I'm starting to think that putting anything=20 > meaningful in=20 > > >> To is a recipe for heartburn. > > >> > > >> -- > > >> Dean > > >> > > >> _______________________________________________ > > >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 24 20:09:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWI6-0000m5-Mo; Tue, 24 Oct 2006 20:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWI5-0000ln-Dv for sip@ietf.org; Tue, 24 Oct 2006 20:06:41 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWI4-0001aT-5D for sip@ietf.org; Tue, 24 Oct 2006 20:06:41 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id 70CE81CC63; Tue, 24 Oct 2006 17:03:40 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> From: EKR Date: Tue, 24 Oct 2006 17:03:40 -0700 In-Reply-To: <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> (Rohan Mahy's message of "Tue, 24 Oct 2006 16:30:09 -0700") Message-ID: <86u01tdzxf.fsf@delta.rtfm.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.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List 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 "Rohan Mahy" writes: > On 10/23/06, Jonathan Rosenberg wrote: >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is >> assigned when you first register a contact, and an additional one is >> created on each refresh. All of the ones accumulated over the >> lifetime of the registration remain valid. Each of them obfuscate >> the AOR and instance ID. Added a description of a stateless >> algorithm for computing these. Lengthy discussion on the privacy >> implications of using them. > > I just reviewed the extremely lengthy thread on GRUU privacy and have > yet to see anything resembling consensus on which privacy or > limited-user requirements we are trying to add here. I'm not sure I agree with this assertion, but I certainly don't think there was consensus on *not* including some privacy mechanisms. > Furthermore I > expect that the mechanism provided could be abused by UAs that want a > private per call for example, creating a lot of registration thrash, > jeopardizing the avalanche restart prevention work in outbound. I don't understand what the security problem you're concerned with is. Can you describe the scenario in more detail? -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 Oct 24 20:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWcW-0006NO-18; Tue, 24 Oct 2006 20:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWcT-0006NJ-UZ for sip@ietf.org; Tue, 24 Oct 2006 20:27:45 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWcS-0005lW-MN for sip@ietf.org; Tue, 24 Oct 2006 20:27:45 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B63121CC5D; Tue, 24 Oct 2006 17:24:53 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] New I-D on UA loose routing In-reply-to: Your message of "Tue, 24 Oct 2006 15:26:49 PDT." <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 24 Oct 2006 17:24:53 -0700 From: EKR Message-Id: <20061025002453.B63121CC5D@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Rohan Mahy wrote: > I have read this draft and I think it is a terrible idea in SIP/2.0 to > send a UA an incoming request with a Route header. If we were working > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea > to consider as baseline behavior, but I think this is too major of a > change from the current spec and state of implementation. > > Lets analyze the requirements described in the document. The unkown > gruu, limited-use gruu, subaddressing, and service invocation > requirements can all be met just by restoring the grid parameter to > its rightful place in GRUU. Not really, no. You'd like to be able to generate limited-use addresses that point to the AOR, not the GRUU. This is reflective of the basic problem: attaching disambiguators to a SIP URI is something that should be done generically, not confined to GRUU. -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 Oct 24 20:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWdQ-0006ej-49; Tue, 24 Oct 2006 20:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWdO-0006eT-Oc for sip@ietf.org; Tue, 24 Oct 2006 20:28:42 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcWdN-0005nj-Ha for sip@ietf.org; Tue, 24 Oct 2006 20:28:42 -0400 Received: from dragon.ariadne.com (failure[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20061025002745m1100rv3hhe>; Wed, 25 Oct 2006 00:28: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 k9P0RNQg015713 for ; Tue, 24 Oct 2006 20:27:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k9P0RNlS015709; Tue, 24 Oct 2006 20:27:23 -0400 Date: Tue, 24 Oct 2006 20:27:23 -0400 Message-Id: <200610250027.k9P0RNlS015709@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA4371111BE46F@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: 3xx for proxy expansion of dial strings. (Was: Re: [Sip] GRUU and Grid alternative) References: <6FC4416DDE56C44DA0AEE67BC7CA4371111BE46F@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 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: "Brian Stucker" Including a tag? You just know someone's going to do it. I suppose ... But when it gets to the UAS, the UAS will respond 481 because it's an in-dialog request and doesn't match any current dialog. People will correct that fairly quickly. 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 Oct 24 20:36:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWhQ-0005RD-Bl; Tue, 24 Oct 2006 20:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcWhP-0005Qv-8A for sip@ietf.org; Tue, 24 Oct 2006 20:32: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 1GcSmb-00085s-04 for sip@ietf.org; Tue, 24 Oct 2006 16:21:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcSJS-000128-KN for sip@ietf.org; Tue, 24 Oct 2006 15:51:55 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9OIsWTH011707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Oct 2006 13:55:14 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 24 Oct 2006 14:51:43 -0500 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Sip] Fwd: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-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 Moving to SIP list with a new subject, lest I derail the important WGLC of dialogusage. On Oct 24, 2006, at 1:19 PM, Francois Audet wrote: > > > Dean said: >> This is simply incorrect (as per RFC 3261), and insisting on >> it going >> forward will only preclude the use of sips: in environments offering >> equally strong hop-by-hop protections such as SIP/UDP over IPSEC, >> which could of course be keyed using the same certs and the same >> cipher-suite as TLS might use. And if you've got the same crypto, do >> you really care which encapsulation is used? The "s" at the end of >> "sips" means "secured", not "specified by RFC 2246". > > > Actually, you are more incorrect. SIPS specifically means TLS for all > the hops up until you reach the target domain. In is only inside the > target domain that alternative to TLS can be used. That's the infamous > "last hop exception" rule. > Yep, that rule was my mistake in 3261, because I could not more effectively ellucidate the point at that time. We have several possible fixes on the table for fixing the broken "last hop" rule: Alternative 1) Keep the usage as is, remembering that the reason it's there is that UAs might well not support TLS server capabilities, and if they're not using something like Outbound, they won't have an existing TLS connection to reuse. In short, this relies on Outbound usage to fix the problem, since it provides a reusable TLS connection that is initiated by the UA as a TLS client. Note that this prevents clients that have some other crypto-protected outbound hop, like IPSEC, from ever using sips: to request that other downstream hops also be protected. These hops might by sheer good fortune be protected, but the requestor neither knows they are nor has a way of expressing this preference. TLS does not have any magic security properties that make it fundamentally more secure than IPSEC or DTLS with the same cyphersuite and key, so why would we want to shoot ourslves in the feet like this? All it accomplishes, AFAIK, is the prevention of secure deployments using UDP. Of course, if we could all agree to deprecate UDP and make TCP/TLS the single mandatory transport, I'd be willing to go along with that. Alternative 2) I believe that sips really should (and was intended to) mean "is cryptographically secured", not "is TLS". We could agree on a similar definition. Given that the current TLS usage doesn't actually assure anything about the cyphersuite and authentication mechanism employed at each hop other than the presumption that the proxies involved are going to try and make good decisions (which is not completely unreasonable, according to our security advisor), why can't we also presume that those same proxies can make equally good decisions about alternative transport encapsulations, such as IPSEC? -- 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 Oct 24 23:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcZoN-000787-Lq; Tue, 24 Oct 2006 23:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcZoM-00077X-Fa for sip@ietf.org; Tue, 24 Oct 2006 23:52:14 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcZoL-0006Jy-1W for sip@ietf.org; Tue, 24 Oct 2006 23:52:14 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 3D3FB2063A for ; Wed, 25 Oct 2006 09:16:56 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 29EE1205DA for ; Wed, 25 Oct 2006 09:16:56 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.163]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:22:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Oct 2006 09:17:15 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Enterprise Role in IMS Network Thread-Index: Acb3xMfbJi9wb4xiTH26jFuudXz8MAAIw4og From: To: X-OriginalArrivalTime: 25 Oct 2006 03:52:07.0467 (UTC) FILETIME=[F103CFB0:01C6F7E8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Sip] SIP Enterprise Role in IMS Network X-BeenThere: sip@ietf.org X-Mailman-Version: 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 not sure if this is the right forum , But please can you let me know what would be the role of a SIP Enterprise Network in an IMS network. I was trying to get some Use Cases for the same. Regards, Srinivasan.K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 01:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcasY-0007TH-1W; Wed, 25 Oct 2006 01:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcasW-0007IP-Dt for sip@ietf.org; Wed, 25 Oct 2006 01:00:36 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gcak7-0004mo-8s for sip@ietf.org; Wed, 25 Oct 2006 00:51:57 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1161751914!11421490!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25528 invoked from network); 25 Oct 2006 04:51:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 25 Oct 2006 04:51:54 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k9P4psLi015696 for ; Tue, 24 Oct 2006 21:51:54 -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 k9P4pran005200 for ; Tue, 24 Oct 2006 23:51:53 -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] SIP Enterprise Role in IMS Network Date: Wed, 25 Oct 2006 12:51:49 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0397AB42@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP Enterprise Role in IMS Network Thread-Index: Acb3xMfbJi9wb4xiTH26jFuudXz8MAAIw4ogAAIkDIA= From: "Avasarala Ranjit-A20990" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 IMS as defined by 3GPP and extended by TISPAN is an architecture defined in terms of functional elements like CSCFs, and other gateway functions. All these elements communicate using SIP. So I would say IMS enterprise network is essentially a SIP wireless enterprise network. =20 Regards=20 Ranjit=20 -----Original Message----- From: srinivasan.kannan@wipro.com [mailto:srinivasan.kannan@wipro.com]=20 Sent: Wednesday, October 25, 2006 9:17 AM To: sip@ietf.org Subject: [Sip] SIP Enterprise Role in IMS Network Hi, I am not sure if this is the right forum , But please can you let me know what would be the role of a SIP Enterprise Network in an IMS network. I was trying to get some Use Cases for the same. Regards, Srinivasan.K _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Oct 25 01:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcatm-0007vA-1n; Wed, 25 Oct 2006 01:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcatk-0007v1-MG for sip@ietf.org; Wed, 25 Oct 2006 01:01:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcati-0006nM-BZ for sip@ietf.org; Wed, 25 Oct 2006 01:01:52 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9P44wrs013932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Oct 2006 23:04:58 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DB2B070@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DB2B070@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44376994-71F7-4D98-9EBD-3DF2CCA6EA64@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 25 Oct 2006 00:01:27 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes Subject: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-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 On Oct 24, 2006, at 3:59 PM, Francois Audet wrote: > I really tought that we had already decided in Montreal that it was > Alternative 1. > That is the plan of record. Of course, the more I think about it, the more convinced I am that the plan is wrong, at least IF we are going to continue to use UDP. > Alternative 2 doens't make sense. If I use https: it means TLS: it > doesn't > mean http over IPsec. It also doesn't mean that you can't use http > over > IPsec. Furthermore, I don't think it would even be possible to > retrofit > this rule into RFC 3261. > Actually, HTTPS means you have TLS all the way to the far end, with no "proxy MITM" weakness. SIPS doesn't mean that. And IMAPS and POPS both mean SSL, not TLS, in common practice. But SMTP, which uses a hop-by-hop relayance model much more similar to SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop security, because that would just be silly for email (as it is silly for SIP, from a security perspective). But if you ask somebody (outside this small group) what the trailing "S" on all those protocols means, they'll probably say it means "secure". So I'd have to say that your argument here, while well-intentioned, is fallacious. As for retrofiting a new rule into RFC 3261 being impossible, I'd argue that it is no more impossible than making sense of the current morass. They're both hard, but not impossible. > In fact, my recollection is that we agreed on Alternative 1 for > starters, > and that we are leaving the issue of the 'last hop exception' to be > decided > later. My worry is that any reasonable resolution of the the last hop exception (which might also need to be a first hop exception, for UDP- only nodes) ends us up right back in the quandary we're currently in -- with no deployable security model short of ignoring half the specification. I'll agree that path #1 is clearly the right way for "explaining what RFC 3261 says". It is not, however, the right way to get to "what RFC 3261 should have said". I can see arguments for saying that an end-to-end TLS, aka SIPSEC:, is what "3261 should have said", and I can see arguments for saying that "reasonably secured on each hop" is what "3261 should have said". I don't find the argument that 3261 should have just said "Just use TLS and ignore the weaknesses" compelling. What we agreed in Montreal was (in the draft you're working on) to complete the task of "explaining what RFC 321 says". But I find the problem of "what it SHOULD have said" far more interesting, because I believe what it currently says is (even if correctly explained) to be badly designed and of limited utility in implementation. -- dean, wearing his paranoid I-told-you-so-and-I'm-not-acing-like-a- chair hat. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 07:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcgXs-0001Vi-Sp; Wed, 25 Oct 2006 07:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcgXr-0001VW-PX for sip@ietf.org; Wed, 25 Oct 2006 07:03:39 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcgXq-0006zs-Gl for sip@ietf.org; Wed, 25 Oct 2006 07:03:39 -0400 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GcgXe-0007mZ-RR; Wed, 25 Oct 2006 07:03:27 -0400 Message-Id: <7.0.1.0.0.20061025070044.03374e98@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 25 Oct 2006 07:03:18 -0400 To: Dean Willis , Francois Audet From: "Joel M. Halpern" Subject: Re: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) In-Reply-To: <44376994-71F7-4D98-9EBD-3DF2CCA6EA64@softarmor.com> References: <1ECE0EB50388174790F9694F77522CCF0DB2B070@zrc2hxm0.corp.nortel.com> <44376994-71F7-4D98-9EBD-3DF2CCA6EA64@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112054e7f78ded728aad39b5c0950bc4d788dc75d10c673c8d76350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 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 tried to say this before. SIPS is frequently (I was going to say normally, but I don't think anything in this situation is normal) understood to mean "SIP with Security". And because SIP is much like Email, I tend to think of it as very parallel to the use of iMAPS / POPS on the first leg, and then whatever happens to get used thereafter. I like the fact that as distinct from email SIPS does actually request that later hops provide security. Yours, Joel M. Halpern PS: Sorry, I don't know why there is such a duplicated list of people, so I am not trimming the dups. At 01:01 AM 10/25/2006, Dean Willis wrote: >But SMTP, which uses a hop-by-hop relayance model much more similar >to SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop >security, because that would just be silly for email (as it is silly >for SIP, from a security perspective). > >But if you ask somebody (outside this small group) what the trailing >"S" on all those protocols means, they'll probably say it means >"secure". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 09:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcikJ-0005Uo-Lu; Wed, 25 Oct 2006 09:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcikG-0004lk-V5 for sip@ietf.org; Wed, 25 Oct 2006 09:24:36 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcifI-0003Bk-Ul for sip@ietf.org; Wed, 25 Oct 2006 09:19:42 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A0A6B15E6; Wed, 25 Oct 2006 15:19:21 +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, 25 Oct 2006 15:18:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 15:18:50 +0200 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 72DF42370; Wed, 25 Oct 2006 16:18:50 +0300 (EEST) Message-ID: <453F643A.5050308@ericsson.com> Date: Wed, 25 Oct 2006 16:18:50 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mary.barnes@comcast.net References: <101820060125.4145.453582730001B36E0000103122007507849C0A029D0E0DD2979D0E03@comcast.net> In-Reply-To: <101820060125.4145.453582730001B36E0000103122007507849C0A029D0E0DD2979D0E03@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 13:18:50.0940 (UTC) FILETIME=[1CAA07C0:01C6F838] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: sip@ietf.org, Mary Barnes , Dean Willis Subject: [Sip] Re: WGLC draft-ietf-sip-consent-framework-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Mary, thanks for your comments. Answers inline: mary.barnes@comcast.net wrote: > I'm posting this from my private email as my Outlook server has been > down this afternoon and doesn't appear to be recovering this evening. > > Draft: draft-ietf-sip-consent-framework-00.txt > Reviewer: Mary Barnes [mary.barnes@nortel.com] > Review Date: 17 October 2006 > Review Deadline: 17 October 2006 > Status: WGLC > > Summary: This draft is on the right track but has an issue and a few > nits, described in the review. > > Issues: > ------- > - Section 4.3: I share the concern that Ben raised in his review with > regards to this framework not making any recommendations about (or > defining) a store-and-forward mechanism. The off-line user issue is > real and it would seem to be a large impediment to deployment of this > functionality if there is not a recommendation for a must implement > mechanism. I don't expect this document to define the functionality > since it is more general, but it does seem a requisite for this draft. I already addressed Ben's comment regarding this issue in a previous email. > Nits: > ------ > - General: the term "Translation Logic" is used almost interchangeably > with "Translation Operation", although only the latter term is defined > in section 2. It would make this document a bit easier to follow, if a > single term was used, provided they do mean the same thing. Also, > there is sometimes an "s" added to the use of the word "logic" - this > likely is incorrect and should be changed if that term remains in the > document. I have removed the 's'es and added the following definition to the Definitions and Terminology Section: Translation logic: The logic that defines a translation operation at a relay. This logic includes the translation's target and recipient URIs. > -Section 3, 1st paragraph following Figure 1: the wording is a bit > awkward and reads as if it's redundant, although it's not. Propose > rewording to something like the following: > OLD: > Thus, an essential aspect of a relay is that of translation. When a > relay receives a request, it translates, following its translation > logic, the Request-URI into one or more additional URIs. That is, > the relay can create outgoing requests to one or more additional > URIs. The translation operation is what creates the consent problem. > NEW: > Thus, an essential aspect of a relay is that of translation. When a > relay receives a request, it translates the Request-URI into one or > more additional URIs. Through this translation operation, > the relay can create outgoing requests to one or more additional > URIs, thus creating the consent problem. I have replaced the text per your suggestion, keeping AC's clarifications in brackets: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI (target URI) into one or more additional URIs (recipient URIs). Through this translation operation, the relay can create outgoing requests to one or more additional URIs, thus creating the consent problem. > > - Section 5.3, 5th paragraph, last sentence: > OLD: > The MESSAGE request also carry ... > NEW: > The MESSAGE request also carries ... Done. > > - Section 5.9, 3rd paragraph, 1st sentence: > OLD: > ... this type of URI-list services behave in a slight different way... > NEW: > ... this type of URI-list services behave in a slightly different way... Done. I have posted a working copy of the new revision of this draft at: http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 09:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcikg-0006LP-0N; Wed, 25 Oct 2006 09:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcikI-0004lk-4x for sip@ietf.org; Wed, 25 Oct 2006 09:24:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcieo-000315-A2 for sip@ietf.org; Wed, 25 Oct 2006 09:19:13 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 175744F0001; Wed, 25 Oct 2006 15:18:47 +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, 25 Oct 2006 15:18:46 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 15:18:46 +0200 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3D4C22370; Wed, 25 Oct 2006 16:18:46 +0300 (EEST) Message-ID: <453F6435.4040405@ericsson.com> Date: Wed, 25 Oct 2006 16:18:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Campbell References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> In-Reply-To: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 13:18:46.0681 (UTC) FILETIME=[1A202890:01C6F838] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: Sip List , Dean Willis Subject: [Sip] Re: WGLC comments for draft-ietf-sip-consent-framework-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Ben, thanks for your comments. Answers inline: Ben Campbell wrote: > Hi, > > Here are my comments on draft-ietf-sip-consent-framework-00. > > General: > > I know this has been discussed, but I have some concerns about the > fact that permissions are not soft-state. This seems contrary to one > of the most basic SIP design principles. I will address some specific > issues below. Assuming we have strong reasons to not use soft-state, > it would be worth including some text in the draft to motivate that > decision. yes, you are right. This has been discussed and the conclusion was that it should be possible for relays to implement soft-states and relays but we did not want to increase the complexity of the mechanism in any way. I agree that we should include more text in the draft explaining this point. I will add the following explanatory text at the end of Section 4.1: OLD: Permissions are valid as long as the context where they were granted is valid or until they are revoked. For example, the permissions obtained by a URI-list SIP service that distributes MESSAGE requests to a set of recipients will be valid as long as the URI-list SIP service exists or until the permissions are revoked. NEW: In principle, permissions are valid as long as the context where they were granted is valid or until they are revoked. For example, the permissions obtained by a URI-list SIP service that distributes MESSAGE requests to a set of recipients will be valid as long as the URI-list SIP service exists or until the permissions are revoked. Additionally, if a recipient is removed from a relay's translation logic, the relay SHOULD delete the permissions related to that recipient. For example, if the registration of a contact URI expires or is otherwise terminated, the registrar deletes the permissions related to that contact address. It is also RECOMMENDED that relays request recipients to refresh their permissions periodically. If a recipient fails to refresh its permissions for a given period of time, the relay SHOULD delete the permissions related to that recipient. This framework does not provide any recommendation for the values of the refreshment intervals because different applications may have different requirements to set those values. > > (editorial) Can we consolidate the ABNF rather than have it scattered > throughout? I would prefer to keep it where each header field is introduced. > > Specifics: > > 3. > >> Since the translation operation is based on local policy or local >> data (such as registrations), it is the vehicle by which a request >> is delivered directly to an endpoint, when it would not otherwise >> be possible to. > > (editorial) This is not generally true. The "exploder" use case, > which is one of the biggest motivators for consent, does not in any > way prevent a sender from directly sending to a particular recipient > without going through the exploder. This _only_ seems true for > proxy/registrars, and then only when permission is applied at > policy-execution time rather than policy manipulation time. (Maybe > I'm missing something.) you are right. The section you are referring to should discuss both reasons for consent (amplifications and translations based on local policy) in a clearer way without confusing them. I will make the following change: OLD: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates, following its translation logic, the Request-URI into one or more additional URIs. That is, the relay can create outgoing requests to one or more additional URIs. The translation operation is what creates the consent problem. Additionally, since the translation operation can result in more than one URI, it is also the source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. Since the translation operation is based on local policy or local data (such as registrations), it is the vehicle by which a request is delivered directly to an endpoint, when it would not otherwise be possible to. In other words, if a spammer has the address of a user, 'user@example.com', it cannot deliver a MESSAGE request to the UA (User Agent) of that user without having access to the registration data that maps 'user@example.com' to the user agent on which that user is present. Thus, it is the usage of this registration data, and more generally, the translation logic, which must be authorized in order to prevent undesired communications. Of course, if the spammer knows the address of the user agent, it will be able to deliver requests directly to it. NEW: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates, following its translation logic, the Request-URI into one or more additional URIs. That is, the relay can create outgoing requests to one or more additional URIs. The translation operation is what creates the consent problem. The consent problem is created by two types of translations: translations based on local data and translations that involve amplifications. Translation operations based on local policy or local data (such as registrations) are the vehicle by which a request is delivered directly to an endpoint, when it would not otherwise be possible to. In other words, if a spammer has the address of a user, 'user@example.com', it cannot deliver a MESSAGE request to the UA (User Agent) of that user without having access to the registration data that maps 'user@example.com' to the user agent on which that user is present. Thus, it is the usage of this registration data, and more generally, the translation logic, which must be authorized in order to prevent undesired communications. Of course, if the spammer knows the address of the user agent, it will be able to deliver requests directly to it. Translation operations that result in more than one URI are a source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. > 4.3 > >> There are several mechanisms to implement store-and-forward message >> services (e.g., with an instant message to email gateway). Any of >> these mechanisms can be used between a user agent and its >> store-and- forward server as long as they agree on which mechanism >> to use. Therefore, this framework does not make any recommendation >> on the interface between user agents and their store-and-forward >> servers. > > > It is not clear to me if store-and-forward servers are a required > (i.e. normative) part of the consent architecture, or if they are > just something that might exist. I infer the first, considering the > draft always assumes the existence of them, and there are clear > issues about handling permissions when you can't get a MESSAGE to the > recipient. > > If we are going to normatively require them, then I have some > heartburn about the fact that there is no specification of how they > work. I don't expect _this_ doc to specify that, but it should be > somewhere. In particular, if we are going to architecturally require > them, we as a community should be concerned about interoperability > between S&F servers and arbitrary UAs, which this document > _explicitly_ punts on. yes, I agree a clarification is needed. I propose to add the following text at the end of Section 4.3: NEW TEXT: Even though store-and-forward servers perform a useful function and they are expected to be deployed in most domains, some domains will not deploy them from day one. However, user agents and relays in domains without store-and-forward servers can still use this consent framework, although with some limitations. In particular, relays in these domains are not able to request permissions from users that are off-line. > Section 4.3: > >> Relays always include SIP URIs and may include HTTP [2] URIs for >> this purpose. Consequently, recipients provide relays with >> permissions using SIP PUBLISH requests or HTTP GET requests. > > Is there normative text somewhere requiring this? If so, I missed it. > Yes, it is in Section 5.4: URIs to Grant Permission: URIs that recipients can use to grant the relay permission to perform the translation described in the document. At least one of these URIs MUST be a SIP or SIPS URI. HTTP and HTTPS URIs MAY also be used. > Section 5.3: > > (General to section): > > (editorial) The organization could use some work. The section opened > discussing what bodies go into the MESSAGE request, then talked > about authentication, then comes _back_ to content of the MESSAGE > request. I suggest consolidating these. Done. > >> Relays MUST obtain permissions from potential recipients before >> adding them to their translation logics. > > Can we make retroactive normative requirements on things like > proxy/registrars? Maybe this should be "Relays that implement this > framework MUST..." Fixed. >> MESSAGE requests sent to request permissions MUST include a >> permission document and SHOULD include a human-readable part in >> their bodies. MESSAGE requests also carry a body part that >> contains the same information as the permission document but in a >> human-readable format so that user agents that do not understand >> permission documents can still process the request and display it >> in a sensible way to the user. > > (editorial) The last clause in the first sentence and the second > sentence seem partially redundant. Also, we may need more spec on > second sentence--how is a user whose UA does not understand this > framework expected to do something useful with it? At least an > example would be helpful I propose the following modification: OLD: MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. MESSAGE requests also carry a body part that contains the same information as the permission document but in a human-readable format so that user agents that do not understand permission documents can still process the request and display it in a sensible way to the user. NEW: MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. The human-readable part contains the same information as the permission document (but in a human-readable format), including the URIs to grant and deny permissions. User agents that do not understand permission documents can still process the request and display it in a sensible way to the user, as they would display any other instant message. This way, even if the user agent does not implement this framework, the (human) user will be able to manually click on the correct URI in order to grant or deny permissions. > Section 5.6: > >> A client gives a relay permission to execute the translation >> described in a permission document by sending a SIP PUBLISH or an >> HTTP GET request to one of the URIs to grant permissions contained >> in the document. Similarly, a client denies a relay permission to >> execute the translation described in a permission document by >> sending a SIP PUBLISH or an HTTP GET request to one of the URIs to >> deny permissions contained in the document. > > If I use PUBLISH, what goes in the body? Does it matter? I infer that > an empty PUBLISH is just fine--if so some clarifying text would help. > Yes, I agree. I have added the following sentence at the end of that paragraph: Requests to grant or deny permissions contain an empty body. > Also, if I deny permissions, and the sender tries again later, do I > get a new permission request? is there a way to say "never bother me > again"? No, we do not describe the "never bother me again" functionality. >> Relays need to ensure that the SIP PUBLISH or the HTTP GET request >> received was generated by the recipient of the translation and not >> by an attacker. > > Normative text? I have replaced "need to" with "MUST". > 5.6.3: > >> The P-Asserted-Identity [4] mechanism can also be used to >> authenticate the sender of a PUBLISH request. However, as >> discussed in RFC 3325 [4], this mechanism should only be used >> within networks of trusted SIP servers. > > (editorial) I seem to recall the statement being stronger than a > non-normative should in 3325. yes, but this is a reference to the normative text in 3325. That is, I do not want to generate a new normative statement here. I just want to point to the already existing one in 3325. This way, if that statement is updated somehow (e.g., by a new RFC), we do not have to revise this RFC as well. > 5.6.3: > > >> Return routability tests do not provide the same level of security >> as SIP identity, but they provide a good-enough security level in >> architectures where the SIP identity mechanism is not available >> (e.g., the current Internet). > > (Editorial) By "good-enough", I think we mean "better-than-nothing" Done. I have replaced "good-enough" with "better-than-nothing" > 5.8: > >> If a client loses this URI for some reason, it needs to wait until >> it receives a new request produced by the translation. Such a >> request will contain a Trigger-Consent header field with a URI. >> That URI will have an escaped Refer-To header field identifying the >> client (i.e., the recipient of the translation). The client needs >> to send a REFER request to the URI in the Trigger-Consent header >> field in order to receive a MESSAGE request from the relay. Such a >> MESSAGE request will contain a permission document with a URI to >> revoke the permission that was previously granted. > > This seems like a fairly kludgy way to work around the fact > permissions live forever. If permissions were soft-state, then we > could dispense with the escape-hatch for lost deny URLs. Also, one of > the likely ways for me to lose the deny URL is if I change to a > different UA, which may not support this framework _at_all_, leaving > me now way to remove the permission. I already addressed this comment above. Now relays are recommended to implement soft-states. > > 5.10 Registrations > > General to section: > > This section makes me even more concerned about the fact that > permission is hard-state. Consider that UA contact addresses tend to > be _highly_ dynamic, and may identify a completely different UA > tomorrow. For example, I get assigned an address of 10.0.0.1 by DHCP. > Tomorrow, _you_ get the same address. The permission still exists > unless someone removed it. I already addressed this comment above. Now relays are recommended to implement soft-states. Additionally, we have added text explaining that when a translation is terminated, the permissions related to it are deleted. We also added an example of how when a registration is terminated, the permissions are deleted. Therefore, in your example, the permissions would be deleted as soon as you unregistered the contact URI you got from DHCP. > > 5.11 > >> A relay executing a translation that involves sending a request to >> a URI from which permissions were obtained previously SHOULD add a >> Trigger-Consent header field to the request. > > If we are to stick with hard-state permissions, I think this should > be a MUST. I will leave it as a SHOULD, considering the recommendation about soft-states we have added. > 6. IANA Considerations > > (editorial) Shouldn't we have some text or a table showing where > these new header fields are allowed? Also, to show for which methods > the 470 response is allowed.? My personal opinion is that those tables are typically out of date shortly after they are created and, thus, are useless most of the time. I would prefer not to add them. > 7. Security Considerations > >> Therefore, it is RECOMMENDED that relays performing translations >> implement this framework. > > There is a bootstrapping problem here--we seem to be placing a > normative requirement on devices that have been previously specified, > such as proxy/registrars If so, this document needs to officially > update those specs, right? well, I guess this is something for the ADs to decide. In any case, we do not need to modify the draft in any way in order to have this RFC update any other RFC. That would be handled by the RFC editor. >> As pointed out in Section 5.6.3, when return routability tests are >> used to authenticate recipients granting or denying permissions, >> the URIs used to grant or deny permissions need to be protected >> from attackers. SIPS URIs provide a good tool to meet this >> requirement, as described in [12]. > > The presence of store-and-forward servers, where the interface > between S&F server and recipient is undefined make introduce security > issues here. If the last hop is not SIP, then SIPS does not > necessarily help. If we are going to leave these vague, then we > should mention this in the security considerations. Good point. I have added the following text at the end of that paragraph: When store-and-forward servers are used, the interface between a user agent and its store-and-forward server may not be based on SIP. In such case, SIPS cannot be used to secure those URIs. It MUST be possible for store-and-forward servers to deliver encrypted and integrity-protected messages to their user agents. I have posted a working copy of the new revision of this draft at: http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 09:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjEX-0007cv-OH; Wed, 25 Oct 2006 09:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjEV-0007ce-Mj; Wed, 25 Oct 2006 09:55:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjEM-0002lL-UZ; Wed, 25 Oct 2006 09:55:51 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BC84E121A; Wed, 25 Oct 2006 15:47:58 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 15:47:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 15:18:48 +0200 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 71E0A2370; Wed, 25 Oct 2006 16:18:48 +0300 (EEST) Message-ID: <453F6438.2080408@ericsson.com> Date: Wed, 25 Oct 2006 16:18:48 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Mahendran, AC" References: <90D469E18343DE47961207F6851040B3F5CEE5@NAEX07.na.qualcomm.com> In-Reply-To: <90D469E18343DE47961207F6851040B3F5CEE5@NAEX07.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 13:18:48.0775 (UTC) FILETIME=[1B5FAD70:01C6F838] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: ac@qualcomm.com, sip@ietf.org, mary.barnes@nortel.com, Dean Willis , drage@lucent.com, sipping@ietf.org Subject: [Sip] Re: WGLC: Comments on draft-ietf-sip-consent-framework-00.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 AC, thanks for your comments. Answers inline: Mahendran, AC wrote: > Hi Gonzallo, > > Here are my comments on draft-ietf-sip-consent-framework-00. > > 1) Section 2 (editorial) " Translation operation: Operation by which > a relay translates the request URI of an incoming request (i.e., the > target URI) into one or more URIs (i.e., recipient URIs) which are > used as the request URIs of one or more outgoing requests. > > Replace 2 instances of the "request URI" with "Request-URI". Done. > > 2) Section 3 (editorial) > > "Thus, an essential aspect of a relay is that of translation. When a > relay receives a request, it translates, following its translation > logic, the Request-URI into one or more additional URIs." > > Add "(target URI)" after "Request-URI" and "(recepient URIs)" after > "one or more additional URIs". Done. Taking into account Mary's comments as well, this text now looks as follows: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI (target URI) into one or more additional URIs (recipient URIs). Through this translation operation, the relay can create outgoing requests to one or more additional URIs, thus creating the consent problem. > 3) Section 4 (Editorial) > > It would be good to add a few descriptive words to describe the > ordering in the sequence of operations (i.e., manipulation, > permission request, permission grant). Though strictly there is no > ordering, normally, manipulation triggers permission requests, which > then triggers permission grant. > I have added the following sentence: The manipulation of a relay's translation logic typically causes the relay to send a permission request, which in turn causes the recipient to grant or deny the relay permissions for the translation. > 4)Section 4.3 (Editorial): > > "Nevertheless, users are not on-line all the time and, so, sometimes > are not able to receive MESSAGE requests." > > Replace "Nevertheless" with "However". Done. > > 5) Section 4.4: > > "Consequently, recipients provide relays with permissions using SIP > PUBLISH requests or HTTP GET requests." > > What are the contents/body of the PUBLISH request? I already clarified that they contain empty bodies when addressing Ben's comments on this document. > Why only HTTP GET? Why can't the recepient use HTTP(XCAP) PUT to > update the permissions document in the relay? There is no need to define multiple methods to do one thing. With one method is enough. Note that this framework is applicable to clients that do not support XCAP. > Btw, is PUBLISH the only SIP method for the recepient to provide > permissions? Why not allow MESSAGE as well? The same reason as above. We want a single method to do this. > 6) Section 5.6.1: > > "Otherwise, the PUBLISH request SHOULD be responded with a 401 > (Unauthorized) response and MUST NOT be processed further." > > The reason for SHOULD (as supposed to MUST) needs to be explained > here. (The same comment applies to 5.6.2, 5.6.4). when talking about response codes, specs generally use "SHOULD" because the server may have a reason to use a different status code. This is a general practice and I do not think we should spend time explaining it in this document. > 7) Section 5.8 > > "At any time, if a client wants to revoke any permission, it uses the > URI it received in the permission document to deny the permissions > it previously granted. If a client loses this URI for some reason, > it needs to wait until it receives a new request produced by the > translation. " > > The usage of "client" in this paragraph is confusing. Based on the > architecture diagram, it'd be better if we use "recepient" instead of > "client". Done. > > 8) Section 5.8 > > In figure 5, when the relay receives the REFER message, it needs to > know which permissions document to the send to the recepient (for > example, the recepient may be a part of multiple SIP URI lists). How > does the relay server know which document B@example.com is requesting > for? because the relay created the URI that was placed in the Trigger-Consent header field when it performed the translation. Therefore, the relay can correlate the incoming REFER (note that we have agreed in a different thread to use PUBLISH instead, although that does not affect this discussion) with the translation the relay performed previously. I have posted a working copy of the new revision of this draft at: http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 10:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gck7Y-0003zN-GJ; Wed, 25 Oct 2006 10:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gck7W-0003zD-8b for sip@ietf.org; Wed, 25 Oct 2006 10:52:42 -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 1Gck7S-0001Ig-85 for sip@ietf.org; Wed, 25 Oct 2006 10:52:42 -0400 Received: from [192.168.1.107] (adsl-68-94-21-164.dsl.rcsntx.swbell.net [68.94.21.164]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9PEqKpt028373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 09:52:25 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <453F6435.4040405@ericsson.com> References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 25 Oct 2006 09:52:14 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.2 (+) X-Scan-Signature: 56904003e9d74831849863e83b1962ec Cc: Sip List , Dean Willis Subject: [Sip] Re: WGLC comments for draft-ietf-sip-consent-framework-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 25, 2006, at 8:18 AM, Gonzalo Camarillo wrote: > Hi Ben, > > thanks for your comments. Answers inline: > > Ben Campbell wrote: >> Hi, >> Here are my comments on draft-ietf-sip-consent-framework-00. >> General: >> I know this has been discussed, but I have some concerns about the >> fact that permissions are not soft-state. This seems contrary to one >> of the most basic SIP design principles. I will address some specific >> issues below. Assuming we have strong reasons to not use soft-state, >> it would be worth including some text in the draft to motivate that >> decision. > > yes, you are right. This has been discussed and the conclusion was > that > it should be possible for relays to implement soft-states and > relays but > we did not want to increase the complexity of the mechanism in any > way. > > I agree that we should include more text in the draft explaining this > point. I will add the following explanatory text at the end of > Section 4.1: > > OLD: > > Permissions are valid as long as the context where they were granted > is valid or until they are revoked. For example, the permissions > obtained by a URI-list SIP service that distributes MESSAGE requests > to a set of recipients will be valid as long as the URI-list SIP > service exists or until the permissions are revoked. > > NEW: > > In principle, permissions are valid as long as the context where > they > were granted is valid or until they are revoked. For example, the > permissions obtained by a URI-list SIP service that distributes > MESSAGE requests to a set of recipients will be valid as long as > the > URI-list SIP service exists or until the permissions are revoked. > > Additionally, if a recipient is removed from a relay's translation > logic, the relay SHOULD delete the permissions related to that > recipient. For example, if the registration of a contact URI > expires > or is otherwise terminated, the registrar deletes the permissions > related to that contact address. > > It is also RECOMMENDED that relays request recipients to refresh > their permissions periodically. If a recipient fails to refresh > its > permissions for a given period of time, the relay SHOULD delete the > permissions related to that recipient. > > This framework does not provide any recommendation for the > values > of the refreshment intervals because different applications may > have different requirements to set those values. > That helps, thanks. > >> (editorial) Can we consolidate the ABNF rather than have it scattered >> throughout? > I would prefer to keep it where each header field is introduced. > OK. >> Specifics: >> 3. >>> Since the translation operation is based on local policy or local >>> data (such as registrations), it is the vehicle by which a request >>> is delivered directly to an endpoint, when it would not otherwise >>> be possible to. >> (editorial) This is not generally true. The "exploder" use case, >> which is one of the biggest motivators for consent, does not in any >> way prevent a sender from directly sending to a particular recipient >> without going through the exploder. This _only_ seems true for >> proxy/registrars, and then only when permission is applied at >> policy-execution time rather than policy manipulation time. (Maybe >> I'm missing something.) > > you are right. The section you are referring to should discuss both > reasons for consent (amplifications and translations based on local > policy) in a clearer way without confusing them. I will make the > following change: > > OLD: > > Thus, an essential aspect of a relay is that of translation. > When a > relay receives a request, it translates, following its translation > logic, the Request-URI into one or more additional URIs. That is, > the relay can create outgoing requests to one or more additional > URIs. The translation operation is what creates the consent > problem. > > Additionally, since the translation operation can result in more > than > one URI, it is also the source of amplification. Servers that > do not > perform translations, such as outbound proxy servers, do not cause > amplification. > > Since the translation operation is based on local policy or local > data (such as registrations), it is the vehicle by which a > request is > delivered directly to an endpoint, when it would not otherwise be > possible to. In other words, if a spammer has the address of a > user, > 'user@example.com', it cannot deliver a MESSAGE request to the UA > (User Agent) of that user without having access to the registration > data that maps 'user@example.com' to the user agent on which that > user is present. Thus, it is the usage of this registration data, > and more generally, the translation logic, which must be authorized > in order to prevent undesired communications. Of course, if the > spammer knows the address of the user agent, it will be able to > deliver requests directly to it. > > NEW: > > Thus, an essential aspect of a relay is that of translation. > When a > relay receives a request, it translates, following its translation > logic, the Request-URI into one or more additional URIs. That is, > the relay can create outgoing requests to one or more additional > URIs. The translation operation is what creates the consent > problem. > > The consent problem is created by two types of translations: > translations based on local data and translations that involve > amplifications. > > Translation operations based on local policy or local data (such as > registrations) are the vehicle by which a request is delivered > directly to an endpoint, when it would not otherwise be possible > to. > In other words, if a spammer has the address of a user, > 'user@example.com', it cannot deliver a MESSAGE request to the UA > (User Agent) of that user without having access to the registration > data that maps 'user@example.com' to the user agent on which that > user is present. Thus, it is the usage of this registration data, > and more generally, the translation logic, which must be authorized > in order to prevent undesired communications. Of course, if the > spammer knows the address of the user agent, it will be able to > deliver requests directly to it. > > Translation operations that result in more than one URI are a > source > of amplification. Servers that do not perform translations, > such as > outbound proxy servers, do not cause amplification. > That helps, thanks. >> 4.3 >>> There are several mechanisms to implement store-and-forward message >>> services (e.g., with an instant message to email gateway). Any of >>> these mechanisms can be used between a user agent and its >>> store-and- forward server as long as they agree on which mechanism >>> to use. Therefore, this framework does not make any recommendation >>> on the interface between user agents and their store-and-forward >>> servers. >> It is not clear to me if store-and-forward servers are a required >> (i.e. normative) part of the consent architecture, or if they are >> just something that might exist. I infer the first, considering the >> draft always assumes the existence of them, and there are clear >> issues about handling permissions when you can't get a MESSAGE to the >> recipient. >> If we are going to normatively require them, then I have some >> heartburn about the fact that there is no specification of how they >> work. I don't expect _this_ doc to specify that, but it should be >> somewhere. In particular, if we are going to architecturally require >> them, we as a community should be concerned about interoperability >> between S&F servers and arbitrary UAs, which this document >> _explicitly_ punts on. > > yes, I agree a clarification is needed. I propose to add the following > text at the end of Section 4.3: > > NEW TEXT: > > Even though store-and-forward servers perform a useful function and > they are expected to be deployed in most domains, some domains will > not deploy them from day one. However, user agents and relays in > domains without store-and-forward servers can still use this > consent > framework, although with some limitations. In particular, > relays in > these domains are not able to request permissions from users > that are > off-line. > I'm still a little queasy with this one. I will respond in a separate email to keep it separate from the other issues. > >> Section 4.3: >>> Relays always include SIP URIs and may include HTTP [2] URIs for >>> this purpose. Consequently, recipients provide relays with >>> permissions using SIP PUBLISH requests or HTTP GET requests. >> Is there normative text somewhere requiring this? If so, I missed it. > Yes, it is in Section 5.4: > > URIs to Grant Permission: URIs that recipients can use to grant the > relay permission to perform the translation described in the > document. At least one of these URIs MUST be a SIP or SIPS URI. > HTTP and HTTPS URIs MAY also be used. > OK, thanks. > >> Section 5.3: >> (General to section): >> (editorial) The organization could use some work. The section opened >> discussing what bodies go into the MESSAGE request, then talked >> about authentication, then comes _back_ to content of the MESSAGE >> request. I suggest consolidating these. > > Done. Thanks. > >>> Relays MUST obtain permissions from potential recipients before >>> adding them to their translation logics. >> Can we make retroactive normative requirements on things like >> proxy/registrars? Maybe this should be "Relays that implement this >> framework MUST..." > > Fixed. > Thanks. > >>> MESSAGE requests sent to request permissions MUST include a >>> permission document and SHOULD include a human-readable part in >>> their bodies. MESSAGE requests also carry a body part that >>> contains the same information as the permission document but in a >>> human-readable format so that user agents that do not understand >>> permission documents can still process the request and display it >>> in a sensible way to the user. >> (editorial) The last clause in the first sentence and the second >> sentence seem partially redundant. Also, we may need more spec on >> second sentence--how is a user whose UA does not understand this >> framework expected to do something useful with it? At least an >> example would be helpful > > I propose the following modification: > > OLD: > > MESSAGE requests sent to request permissions MUST include a > permission document and SHOULD include a human-readable part in > their > bodies. MESSAGE requests also carry a body part that contains the > same information as the permission document but in a human-readable > format so that user agents that do not understand permission > documents can still process the request and display it in a > sensible > way to the user. > > NEW: > > MESSAGE requests sent to request permissions MUST include a > permission document and SHOULD include a human-readable part in > their > bodies. The human-readable part contains the same information > as the > permission document (but in a human-readable format), including the > URIs to grant and deny permissions. User agents that do not > understand permission documents can still process the request and > display it in a sensible way to the user, as they would display any > other instant message. This way, even if the user agent does not > implement this framework, the (human) user will be able to manually > click on the correct URI in order to grant or deny permissions. > Thanks, that helps. > >> Section 5.6: >>> A client gives a relay permission to execute the translation >>> described in a permission document by sending a SIP PUBLISH or an >>> HTTP GET request to one of the URIs to grant permissions contained >>> in the document. Similarly, a client denies a relay permission >>> to execute the translation described in a permission document by >>> sending a SIP PUBLISH or an HTTP GET request to one of the URIs to >>> deny permissions contained in the document. >> If I use PUBLISH, what goes in the body? Does it matter? I infer that >> an empty PUBLISH is just fine--if so some clarifying text would help. > Yes, I agree. I have added the following sentence at the end of that > paragraph: > > Requests to grant or deny permissions contain an empty body. > Thanks. >> Also, if I deny permissions, and the sender tries again later, do I >> get a new permission request? is there a way to say "never bother me >> again"? > > No, we do not describe the "never bother me again" functionality. > OK, it is probably not worth pursuing at this point. >>> Relays need to ensure that the SIP PUBLISH or the HTTP GET >>> request received was generated by the recipient of the >>> translation and not >>> by an attacker. >> Normative text? > > I have replaced "need to" with "MUST". Thanks >> 5.6.3: >>> The P-Asserted-Identity [4] mechanism can also be used to >>> authenticate the sender of a PUBLISH request. However, as >>> discussed in RFC 3325 [4], this mechanism should only be used >>> within networks of trusted SIP servers. >> (editorial) I seem to recall the statement being stronger than a >> non-normative should in 3325. > > yes, but this is a reference to the normative text in 3325. That is, I > do not want to generate a new normative statement here. I just want to > point to the already existing one in 3325. This way, if that statement > is updated somehow (e.g., by a new RFC), we do not have to revise this > RFC as well. > OK >> 5.6.3: >>> Return routability tests do not provide the same level of security >>> as SIP identity, but they provide a good-enough security level in >>> architectures where the SIP identity mechanism is not available >>> (e.g., the current Internet). >> (Editorial) By "good-enough", I think we mean "better-than-nothing" > > Done. I have replaced "good-enough" with "better-than-nothing" > Thanks >> 5.8: >>> If a client loses this URI for some reason, it needs to wait until >>> it receives a new request produced by the translation. Such a >>> request will contain a Trigger-Consent header field with a URI. >>> That URI will have an escaped Refer-To header field identifying the >>> client (i.e., the recipient of the translation). The client needs >>> to send a REFER request to the URI in the Trigger-Consent header >>> field in order to receive a MESSAGE request from the relay. Such a >>> MESSAGE request will contain a permission document with a URI to >>> revoke the permission that was previously granted. >> This seems like a fairly kludgy way to work around the fact >> permissions live forever. If permissions were soft-state, then we >> could dispense with the escape-hatch for lost deny URLs. Also, one of >> the likely ways for me to lose the deny URL is if I change to a >> different UA, which may not support this framework _at_all_, leaving >> me now way to remove the permission. > > I already addressed this comment above. Now relays are recommended to > implement soft-states. > OK >> 5.10 Registrations >> General to section: >> This section makes me even more concerned about the fact that >> permission is hard-state. Consider that UA contact addresses tend to >> be _highly_ dynamic, and may identify a completely different UA >> tomorrow. For example, I get assigned an address of 10.0.0.1 by DHCP. >> Tomorrow, _you_ get the same address. The permission still exists >> unless someone removed it. > > I already addressed this comment above. Now relays are recommended to > implement soft-states. Additionally, we have added text explaining > that > when a translation is terminated, the permissions related to it are > deleted. We also added an example of how when a registration is > terminated, the permissions are deleted. Therefore, in your > example, the > permissions would be deleted as soon as you unregistered the > contact URI > you got from DHCP. > OK >> 5.11 >>> A relay executing a translation that involves sending a request to >>> a URI from which permissions were obtained previously SHOULD add >>> a Trigger-Consent header field to the request. >> If we are to stick with hard-state permissions, I think this should >> be a MUST. > > I will leave it as a SHOULD, considering the recommendation about > soft-states we have added. > OK >> 6. IANA Considerations >> (editorial) Shouldn't we have some text or a table showing where >> these new header fields are allowed? Also, to show for which methods >> the 470 response is allowed.? > > My personal opinion is that those tables are typically out of date > shortly after they are created and, thus, are useless most of the > time. > I would prefer not to add them. Do you object to the format or the content of such tables? > >> 7. Security Considerations >>> Therefore, it is RECOMMENDED that relays performing translations >>> implement this framework. >> There is a bootstrapping problem here--we seem to be placing a >> normative requirement on devices that have been previously specified, >> such as proxy/registrars If so, this document needs to officially >> update those specs, right? > > well, I guess this is something for the ADs to decide. In any case, we > do not need to modify the draft in any way in order to have this RFC > update any other RFC. That would be handled by the RFC editor. OK > >>> As pointed out in Section 5.6.3, when return routability tests >>> are used to authenticate recipients granting or denying permissions, >>> the URIs used to grant or deny permissions need to be protected >>> from attackers. SIPS URIs provide a good tool to meet this >>> requirement, as described in [12]. >> The presence of store-and-forward servers, where the interface >> between S&F server and recipient is undefined make introduce security >> issues here. If the last hop is not SIP, then SIPS does not >> necessarily help. If we are going to leave these vague, then we >> should mention this in the security considerations. > > Good point. I have added the following text at the end of that > paragraph: > > When store-and-forward servers are used, the interface between a > user > agent and its store-and-forward server may not be based on SIP. In > such case, SIPS cannot be used to secure those URIs. It MUST be > possible for store-and-forward servers to deliver encrypted and > integrity-protected messages to their user agents. > > Can we put normative requirements on the piece of the architecture that may or may not exist? This is sort of like pinning the tail on the rumor of a donkey. My point was really that we need to document that the security issue exists, depending on what these devices do, rather than to state what they must do. > I have posted a working copy of the new revision of this draft at: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent- > framework-01.txt > > Cheers, > > Gonzalo > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 11:03:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckFp-0001Su-9Q; Wed, 25 Oct 2006 11:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckFn-0001Si-SC for sip@ietf.org; Wed, 25 Oct 2006 11:01:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckFm-00037Q-8I for sip@ietf.org; Wed, 25 Oct 2006 11:01:15 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 02F2F11AD; Wed, 25 Oct 2006 17:01:00 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:59:50 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:22:13 +0200 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 248032370; Wed, 25 Oct 2006 17:22:13 +0300 (EEST) Message-ID: <453F7314.7060502@ericsson.com> Date: Wed, 25 Oct 2006 17:22:12 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Campbell References: <03939304-4473-4E5A-BC8C-F39BEBCF078B@estacado.net> In-Reply-To: <03939304-4473-4E5A-BC8C-F39BEBCF078B@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 14:22:13.0383 (UTC) FILETIME=[F718C970:01C6F840] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Sip List , Dean Willis Subject: [Sip] Re: WGLC comments for draft-ietf-sipping-consent-format-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Ben, thanks for your comments. Answers inline: Ben Campbell wrote: > Hi, > > General comments: > > (editorial) Personal pet-peeve: It is much more friendly to the > reader to use the form, "...defined in RFCXXX [8]", than to say > "...defined in [8]." Otherwise they have to keep referring to the > reference section. I realize that is hard to do with > works-in-process, but we could use a descriptive name. (I mention > this in general as it is pervasive to the draft.) yes, you are probably right. In any case, this is a change we may be able to do in AUTH48, when all the references have become RFCs. Doing a global replace should not be a big deal for the RFC editor at that point. > > 3. > >> This section defines the new conditions and actions defined by this >> specification. This specification does not define any new >> transformation. > > I am at a loss to understand how transformations would be used at all > for this purpose. > I have clarified that point adding the following sentence at the end of the first paragraph of Section 3: However, even though permission documents need to have a transformation part to comply to the common policy syntax, effectively, permission documents do not make any use of transformations. > 3.1.1. > >> The elements and MUST contain a scheme when they >> appear in a permission document. > > We are talking about the "id" attribute in each of those, correct? yes. I have clarified it as follows: The 'id' attribute in the elements and MUST contain a scheme when these elements appear in a permission document. > Also, is the element permissible in ? I don't > understand how it would be used, particularly since the framework > does not allow wildcarding of identity. you are right. The framework disallows to wildcard recipient URIs. However, in the future, there might be use cases for wildcarded recipients. Therefore, it seems enough forbidding them in the framework. No need to restrict the syntax of the document format. In any case, if you feel very strongly about this, I can add a normative sentence forbidding them in the format as well. >> For PUBLISH requests that are authenticated using the SIP Identity >> mechanism, the identity of the sender of the PUBLISH request is >> equal to the SIP URI in the From header field of the request, >> assuming that the signature in the Identity header field has been >> validated. > > Should we have a normative statement that the signature MUST be > validated? I believe that the paragraph is clear enough: if the signature is validated, then the identity is the one in the From header field. Otherwise, the sender cannot be considered authenticated. However, feel free to suggest how to modify the paragraph if you think it can be clarified even further. > >> P-Asserted-Identity [5], as described in [9]. For PUBLISH requests >> that are authenticated using the P-Asserted-Identity mechanism, >> the identity of the sender of the PUBLISH request is equal to the >> P-Asserted-Identity header field of the request. > > Need to mention the P-Asserted-Identity requires the request to have > come from a trusted element. This part of the document describes where to get the identity from when using different authentication mechanism; not how to use those mechanisms. Implementors should check the references specifying those mechanisms to implement them anyway. So, I do not think we need to clarify how P-Asserted-Identify works even further. > > 3.1.2: > >> >> The sender condition is matched against the URI of the sender of >> the request that is used as input for a translation. Sender >> conditions can contain the same elements and attributes as identity >> conditions. > > does this include the same rules about having a scheme in > and ? > > Also, is allowed? It seems to make more sense for > than for no, those rules do not apply to senders. In fact, further down in the same section, the document explains how to compute a URI from an id attribute in a or element without scheme. > > 3.1.2.2 > >> For requests that are authenticated using SIP Digest, the identity >> of the sender is set equal to the user and domain part of the SIP >> Address of Record (AOR) for the user that has authenticated > > why not just the whole SIP AoR? That is, why did we mention user and > domain parts, rather than just take the AoR URI as a whole? you are right. I have removed "the user and domain part of" >> For requests that are authenticated using RFC 3325 [5], the >> identity of the sender is equal to the username and domain parts of >> the SIP URI in the P-Asserted-ID header field. If there are >> multiple values for the P-Asserted-ID header field (there can be >> one sip URI and one tel URI [10]), then each of them is used for >> the comparisons outlined in [8], and if either of them match a >> or element, it is considered a match. > > why do we call out user and domain parts, instead of just taking the > URI as a whole? I have removed " the username and domain parts of" here as well. > 3.1.2.3 > > what are the consequences of being unable to convert the id? then, no sender will match the element in the document and the permission document would be useless. > > 3.2.1: > > The use of the transl-handling URIs seems under-specified to me. The > framework document mentions you can send a SIP PUBLISH or an HTTP > get. In the case of publish, what do you publish? An empty document? > HTTP is easier to figure out, but it is still not explicit. What > about other schema? Per my previous email addressing your comments on the framework, I have clarified that point. Regarding other schemas, what do you have in mind? Being able to provide SIP and HTTP URIs seems enough for all practical purposes. > > 4. > > Should the two elements be elements instead? > Fixed. I have posted a working version of the next revision of this draft at: http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-consent-format-01.txt Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 11:32:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckiA-0006o6-Of; Wed, 25 Oct 2006 11:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcki7-0006gV-Hd for sip@ietf.org; Wed, 25 Oct 2006 11:30:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcki0-0000hE-TL for sip@ietf.org; Wed, 25 Oct 2006 11:30:31 -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 k9PFUKYI051871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Oct 2006 10:30:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <2E633306-963F-4000-89B8-9D49C1A9A460@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP List From: Robert Sparks Date: Wed, 25 Oct 2006 10:30:20 -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: abda3837e791065a13ac6f11cf8e625a Subject: [Sip] SIPit 19 summary X-BeenThere: sip@ietf.org X-Mailman-Version: 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 message is somewhat long, and may not survive some mail applications attempts to be helpful with formatting. I've also placed it at http://www.sipit.net/report19.txt) SIPit 19 took place Oct 16-20, 2006 at the University of New Hampshire InterOperability Laboratory (www.iol.unh.edu). There were 140 attendees from 73 companies visiting from 16 countries present. There were 79 teams and 90 distinct implementations. The Interoperability Laboratory did a spectacular job of providing a rock-solid network for us to test on. (For those who haven't been to a SIPit, it is a particularly intense network torturing environment). The majority of the spec-arguments during testing centered around how to handle early media and early dialogs. There was also a non-trivial subset of the implementers that were confused about whether REGISTER and PUBLISH create dialogs (much of this confusion seems to come from the presence of to-tags in the 200 OK responses to REGISTER in the examples in 3261). There were a number of interesting questions about edge cases that I will send to the appropriate IETF lists separately. We tried something different for collecting data for this report at this SIPit. We utilized a web-based automated survey tool. As a result, we collected information on more questions than we usually do, so this report is a bit long. A side-effect is that the accuracy of the information is probably a little lower. Almost all of what's below is self-reported, and its unavoidable that for any given question an implementer or two didn't understand, or didn't know the answer. So, with an appropriate level of respect for errors in sampling, here's what we found: The roles represented (some implementations act in more than one role): 36 endpoint 19 proxy/registrar 8 standalone proxy 4 redirect server 4 gateway 15 automaton UA (voicemail, conference, etc.) 17 b2bua/sbc 6 ua w/ signalling but no media 8 test/monitoring tool Implementations using each transport for SIP messages: UDP 100% TCP 82% TLS 45% (server auth only) TLS 36% (server or mutual auth) SCTP 6% DTLS 0% 10% of the implementations supported SIP over multicast. 30% supported SIP over IPv6. 70% of the implementations correctly reassembled fragmented UDP. Proper use of DNS for SIP continues to rise: Full RFC3263 use of DNS 59% SRV only 14% A records only 15% no DNS support 12% Support for various items: 32% ENUM 65% rport 30% multiplexing SIP/STUN 14% SIGCOMP 25% RFC4320 fixes 14% Identity 30% connect-reuse 14 of the implementations claimed support for outbound. Interoperability around this draft was fairly low, but the implementers are aggressively improving it. 15 implementations claimed support for some version of GRUU. Nothing worked together before code changes at the event. By the end a few teams were getting scenarios to work. Only 3 implementations were attempting to support the consent framework. The endpoints implemented these methods: 100% INVITE and ACK 100% CANCEL 100% BYE 96% REGISTER 81% OPTIONS 76% SUBSCRIBE 80% NOTIFY 56% PRACK 52% MESSAGE 74% INFO 63% UPDATE 80% REFER 41% PUBLISH The endpoints implemented these extensions: 67% RFC3891: replaces 63% RFC4028: session-timer 17% RFC3327: path 11% RFC3840: pref 4% RFC3841: caller-prefs 26% RFC3323: privacy 6% RFC4538: target-dialog 7% RFC4488: norefersub 56% RFC3262: 100rel 3% RFC3994: indication of message composition 44% of the endpoints implemented sipping-cc-transfer When asked about STUN support, the client implementations replied: 6% I implement all the client requirements of draft-ietf-behave- rfc3489bis 6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis 13% I implement all of the client requirements of RFC3489 7% I implement some, but not all, of the client requirements of RFC3489 59% I do not implement STUN as a client 9% Other There are still a large number of endpoints (25%) that do not use symmetric RTP. There were only a couple of TURN client implementations. We had several STUN servers and 2 TURN servers. There were only 3 ICE implementations, and only one of those was at the current version. Interoperability was reasonably high, but not seamless. The issues with interoperability were all implementation problems. I asked the endpoint implementations to characterize their handling of S/MIME: 15% I break if someone sends me S/MIME 22% I pretend S/MIME doesn't exist if it shows up 35% I don't pay attention to S/MIME, but will proxy it or hand it to my application 7% I pay attention to S/MIME I receive, but don't send any 2% I don't pay attention to S/MIME I receive, but I do send some 4% I try to do something useful with S/MIME I receive and send 15% Other I asked the same question about multipart mime support: 7% I break if someone sends me multipart/mime 20% I pretend multipart/mime doesn't exist if someone sends it to me 19% I ignore multipart/mime but will proxy it or hand it to my application if it shows up 15% I try to do something useful with multipart/mime I receive, but I never send it 4% I ignore multipart/mime that I receive, but I try to do something useful with multipart/mime I send 22% I try to do something useful with multipart/mime I send and receive 13% Other 48% of the endpoint implementations claimed to correctly handle merged requests. Here is how the endpoints said they handled receiving 200 OKs from more than one branch of a forked INVITE: 54% I send BYEs to all but one branch 6% I use all of them (perhaps mixing the different media streams locally) 16% I don't handle this case gracefully 11% Other Here is a sample of how endpoint implementors replied when asked how they handled early media from more than one leg: * We allow multiple RTP streams with an affinity to the last one. * First Media received is played until 200. * The first 183 will be honored in case of the UAC. The rest will be dropped. * Allow media from only negotiated address. Ignore media until negotiated (offer-answer exchanged). * Listen to most recently started stream. * all early media will passed on to the UA. * pick the one who most recently sent me a criticial threshold of media. * Play only one media stream and ignore others. * The last sdp received override previous one. * First 18x message goes through, rest dropped. * Open voice only with the first one, but answer all of the 18x * We will use the first recieved * I ignore early media * All get relayed - (all rendered leave final choice to recipient UA) * Last early media replaces previous * We update media as the 18x's come in. 200OK media will be the confirmed media channel. * Take the first Interestingly, 15% of the endpoints supported DHCP option 120. This is how the endpoints (that actually handled media) described their use of RTCP: 38% I fully implement RTCP and use the RTCP from my peers 20% I send some RTCP, and open a port to receive RTCP, but I ignore any packets I receive 18% I never send RTCP, but I do open a port for receiving (and ignoring) it 24% I don't even open a port for RTCP There were 12 (roughly 25%) endpoints testing SRTP support. Keying was predominantly sdes. Interoperability is not yet high, but more pairs got something working than at SIPit 18. There were only 4 endpoints supporting comedia. There were 22 proxies present. The proxy implementers characterized their handling of infinite loop prevention this way: 0% I implement loop detection as per the sip-loop-fix draft 45% I perform RFC3261 loop detection 45% I don't loop detect, but do pay attention to max-forwards 10% I don't loop detect or look at max-forwards I asked proxies "Will you proxy a request with a RURI containing an unknown scheme (such as splork:) when there is a Route header field whose first value is a SIP URI you can resolve?" and got these responses: 32% Yes 68% No Half of the proxies in attendence actively participated in session- timer. There were 9 implementations (41%) that categorized themselves as proxies that would not forward an unknown method. Two-thirds of the proxies claimed to properly handle SIPS. None of the proxies made use of 3840 or 3841 information (capabilities and caller-prefs) There were 19 registrars. 7 of the registrars (37%) accepted non-sip or sips Contacts in a registration 11 (58%) would accept a REGISTER request that had a multipart-mime body (almost all ignored it) 1 would accept an S/MIME signed or encrypted register Half of the border-elements (B2BUA/SBC-like implementations) could be configured to forward unknown methods. 75% could be configured to forward unknown SDP lines There were 41 SIP Events implementations present 15 (37%) of them would send unsolicted notifies (there were 2 more things that ONLY sent unsolicited notifies). They supported these event packages: 29 refer 23 message-summary 14 presence 12 dialog 5 reg 4 ua-profile (sipping-config-framework) 4 conference 2 reg gruu extension (sipping-gruu-reg-event) 2 certificate/credentials (sip-certs) 1 session-spec-policy (sipping-policy) 1 kpml 0 vx-rtcpxr (sipping-rtcp-summary) Only 4 (10%) supported winfo 4 supported event-list 37% of the implementation supporting SIP Events supported PUBLISH Of the 14 implementations supporting event presence, there was support for the following document formats: 12 base PIDF only 2 RPID 0 CIPID 0 timed presence 0 PIDF-LO 0 prescaps-ext 5 implementations supported XCAP 7 supported pres-rules I asked all the implentations present which P- headers they actively supported: (I suspect many of the respondents who passively let the headers pass or ignore them answered yes, so these numbers, more than any others of the above are probably inflated) 28 P-Asserted-Identity 21 P-Preferred-Identity 10 P-Called-Party-ID 9 P-Associated-URI 9 P-Access-Network-Info 8 P-Charging-Vector 6 P-Visited-Network-ID 5 P-Charging-Function-Address 4 P-User-Database 4 P-DCS-* (any of the P-DCS headers) 3 P-Media-Authorization That's it. Please let me know if there are different questions you want to see asked next SIPit. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 12:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclY2-0002Cn-Bz; Wed, 25 Oct 2006 12:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclY1-0002Ci-Ig for sip@ietf.org; Wed, 25 Oct 2006 12:24:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclXs-0002aH-L4 for sip@ietf.org; Wed, 25 Oct 2006 12:24:09 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A6C03AE4; Wed, 25 Oct 2006 18:23:48 +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, 25 Oct 2006 18:23:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 18:23:48 +0200 Received: from [131.160.126.8] (rvi2-126-8.lmf.ericsson.se [131.160.126.8]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EC4102370; Wed, 25 Oct 2006 19:23:47 +0300 (EEST) Message-ID: <453F8F92.8070003@ericsson.com> Date: Wed, 25 Oct 2006 19:23:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Re: WGLC comments for draft-ietf-sipping-consent-format-00 References: <03939304-4473-4E5A-BC8C-F39BEBCF078B@estacado.net> <453F7314.7060502@ericsson.com> In-Reply-To: <453F7314.7060502@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 16:23:48.0387 (UTC) FILETIME=[F3420F30:01C6F851] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: 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 Hi, I replied to Ben's email and we ended up in the SIP mailing list, while this draft should be discussed in SIPPING. Please, if you have any comments, use the SIPPING mailing list instead. Cheers, Gonzalo Gonzalo Camarillo wrote: > Hi Ben, > > thanks for your comments. Answers inline: > > Ben Campbell wrote: >> Hi, >> >> General comments: >> >> (editorial) Personal pet-peeve: It is much more friendly to the >> reader to use the form, "...defined in RFCXXX [8]", than to say >> "...defined in [8]." Otherwise they have to keep referring to the >> reference section. I realize that is hard to do with >> works-in-process, but we could use a descriptive name. (I mention >> this in general as it is pervasive to the draft.) > > yes, you are probably right. In any case, this is a change we may be > able to do in AUTH48, when all the references have become RFCs. Doing a > global replace should not be a big deal for the RFC editor at that point. > >> >> 3. >> >>> This section defines the new conditions and actions defined by this >>> specification. This specification does not define any new >>> transformation. >> >> I am at a loss to understand how transformations would be used at all >> for this purpose. >> > > I have clarified that point adding the following sentence at the end of > the first paragraph of Section 3: > > However, even though permission documents need to > have a transformation part to comply to the common policy syntax, > effectively, permission documents do not make any use of > transformations. > >> 3.1.1. >> >>> The elements and MUST contain a scheme when they >>> appear in a permission document. >> >> We are talking about the "id" attribute in each of those, correct? > > yes. I have clarified it as follows: > > The 'id' attribute in the elements and MUST > contain a scheme when these elements appear in a permission document. > >> Also, is the element permissible in ? I don't >> understand how it would be used, particularly since the framework >> does not allow wildcarding of identity. > > you are right. The framework disallows to wildcard recipient URIs. > However, in the future, there might be use cases for wildcarded > recipients. Therefore, it seems enough forbidding them in the framework. > No need to restrict the syntax of the document format. > > In any case, if you feel very strongly about this, I can add a normative > sentence forbidding them in the format as well. > > >>> For PUBLISH requests that are authenticated using the SIP Identity >>> mechanism, the identity of the sender of the PUBLISH request is >>> equal to the SIP URI in the From header field of the request, >>> assuming that the signature in the Identity header field has been >>> validated. >> >> Should we have a normative statement that the signature MUST be >> validated? > > I believe that the paragraph is clear enough: if the signature is > validated, then the identity is the one in the From header field. > Otherwise, the sender cannot be considered authenticated. However, feel > free to suggest how to modify the paragraph if you think it can be > clarified even further. > >> >>> P-Asserted-Identity [5], as described in [9]. For PUBLISH requests >>> that are authenticated using the P-Asserted-Identity mechanism, the >>> identity of the sender of the PUBLISH request is equal to the >>> P-Asserted-Identity header field of the request. >> >> Need to mention the P-Asserted-Identity requires the request to have >> come from a trusted element. > > This part of the document describes where to get the identity from when > using different authentication mechanism; not how to use those > mechanisms. Implementors should check the references specifying those > mechanisms to implement them anyway. So, I do not think we need to > clarify how P-Asserted-Identify works even further. > >> >> 3.1.2: >> >>> >>> The sender condition is matched against the URI of the sender of >>> the request that is used as input for a translation. Sender >>> conditions can contain the same elements and attributes as identity >>> conditions. >> >> does this include the same rules about having a scheme in >> and ? >> >> Also, is allowed? It seems to make more sense for >> than for > > no, those rules do not apply to senders. In fact, further down in the > same section, the document explains how to compute a URI from an id > attribute in a or element without scheme. > >> >> 3.1.2.2 >> >>> For requests that are authenticated using SIP Digest, the identity >>> of the sender is set equal to the user and domain part of the SIP >>> Address of Record (AOR) for the user that has authenticated >> >> why not just the whole SIP AoR? That is, why did we mention user and >> domain parts, rather than just take the AoR URI as a whole? > > you are right. I have removed "the user and domain part of" > >>> For requests that are authenticated using RFC 3325 [5], the >>> identity of the sender is equal to the username and domain parts of >>> the SIP URI in the P-Asserted-ID header field. If there are >>> multiple values for the P-Asserted-ID header field (there can be >>> one sip URI and one tel URI [10]), then each of them is used for >>> the comparisons outlined in [8], and if either of them match a >>> or element, it is considered a match. >> >> why do we call out user and domain parts, instead of just taking the >> URI as a whole? > > I have removed " the username and domain parts of" here as well. > > >> 3.1.2.3 >> >> what are the consequences of being unable to convert the id? > > then, no sender will match the element in the document and the > permission document would be useless. > >> >> 3.2.1: >> >> The use of the transl-handling URIs seems under-specified to me. The >> framework document mentions you can send a SIP PUBLISH or an HTTP >> get. In the case of publish, what do you publish? An empty document? >> HTTP is easier to figure out, but it is still not explicit. What >> about other schema? > > Per my previous email addressing your comments on the framework, I have > clarified that point. > > Regarding other schemas, what do you have in mind? Being able to provide > SIP and HTTP URIs seems enough for all practical purposes. > >> >> 4. >> >> Should the two elements be elements instead? >> > > Fixed. > > > I have posted a working version of the next revision of this draft at: > http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-consent-format-01.txt > > > Thanks, > > Gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 25 15:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco7t-0003aH-O6; Wed, 25 Oct 2006 15:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gco7s-0003Wl-He for sip@ietf.org; Wed, 25 Oct 2006 15:09:20 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gco7q-0000np-5U for sip@ietf.org; Wed, 25 Oct 2006 15:09:20 -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 k9PJ27h11490; Wed, 25 Oct 2006 15:02:07 -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: Wed, 25 Oct 2006 14:08:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DB775C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <44376994-71F7-4D98-9EBD-3DF2CCA6EA64@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS meaning Thread-Index: Acb38rHonGeXM8+EQ4S+W6zgHE0x2QAdG68Q From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes Subject: [Sip] RE: TLS meaning X-BeenThere: sip@ietf.org X-Mailman-Version: 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, to summarize, you are NOT happy with the current consensus, and you=20 are proposing something completely different, i.e., that instead of just the current cludgy "last-hop exception rule", we also add a new "first-hop=20 exception" (and I would imagine a new "any hop exception" rule)? Unlike the current "last hop exception rule" which imposes absolutely no security requirements, your "any hop exception rule" would change this it to a "decent security equivalent to TLS" rule. This would entail finding all the instances of "TLS" in RFC 3261 and make the according changes. This is a gigantic change from RFC 2961. I don't think it is reasonable. It is orders of magnitude bigger than what is discussed in=20 draft-audet-sip-sips-guidelines which does NOT attempt to redefine the meaning of sips, and does NOT invalidate RFC 3261. My take is that using other protocols than TLS is perfectly fine. However, it does not mean that we should be using sips in that case. I'd argue that using sip is perfectly fine in those cases. If a network for example relies on IPsec, maybe there is no need to use sips at all. I think we need to be pragmatic here. We can not invalidate huge chunks of=20 RFC 3261 in the way you are proposing. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 24, 2006 10:01 PM > To: Audet, Francois (SC100:3055) > Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary=20 > (RICH2:AR00); Gonzalo Camarillo; IETF SIP List > Subject: Re: TLS meaning (was Re: [Sipping] WGLC:=20 > draft-ietf-sipping-dialogusage-03.txt) >=20 >=20 > On Oct 24, 2006, at 3:59 PM, Francois Audet wrote: > > I really tought that we had already decided in Montreal that it was=20 > > Alternative 1. > > >=20 > That is the plan of record. Of course, the more I think about=20 > it, the more convinced I am that the plan is wrong, at least=20 > IF we are going to continue to use UDP. >=20 > > Alternative 2 doens't make sense. If I use https: it means TLS: it=20 > > doesn't mean http over IPsec. It also doesn't mean that you=20 > can't use=20 > > http over IPsec. Furthermore, I don't think it would even=20 > be possible=20 > > to retrofit this rule into RFC 3261. > > >=20 >=20 > Actually, HTTPS means you have TLS all the way to the far=20 > end, with no "proxy MITM" weakness. SIPS doesn't mean that. >=20 > And IMAPS and POPS both mean SSL, not TLS, in common practice. >=20 > But SMTP, which uses a hop-by-hop relayance model much more=20 > similar to SIP than HTTP is, doesn't have an SMPTS to insist=20 > on hop-by-hop security, because that would just be silly for=20 > email (as it is silly for SIP, from a security perspective). >=20 > But if you ask somebody (outside this small group) what the=20 > trailing "S" on all those protocols means, they'll probably=20 > say it means "secure". >=20 > So I'd have to say that your argument here, while=20 > well-intentioned, is fallacious. As for retrofiting a new=20 > rule into RFC 3261 being impossible, I'd argue that it is no=20 > more impossible than making sense of the current morass.=20 > They're both hard, but not impossible. >=20 >=20 > > In fact, my recollection is that we agreed on Alternative 1 for=20 > > starters, and that we are leaving the issue of the 'last hop=20 > > exception' to be decided later. >=20 > My worry is that any reasonable resolution of the the last=20 > hop exception (which might also need to be a first hop=20 > exception, for UDP- only nodes) ends us up right back in the=20 > quandary we're currently in > -- with no deployable security model short of ignoring half=20 > the specification. >=20 > I'll agree that path #1 is clearly the right way for=20 > "explaining what RFC 3261 says". It is not, however, the=20 > right way to get to "what RFC > 3261 should have said". >=20 > I can see arguments for saying that an end-to-end TLS, aka=20 > SIPSEC:, is what "3261 should have said", and I can see=20 > arguments for saying that "reasonably secured on each hop" is=20 > what "3261 should have said". I don't find the argument that=20 > 3261 should have just said "Just use TLS and ignore the=20 > weaknesses" compelling. >=20 > What we agreed in Montreal was (in the draft you're working=20 > on) to complete the task of "explaining what RFC 321 says".=20 > But I find the problem of "what it SHOULD have said" far more=20 > interesting, because I believe what it currently says is=20 > (even if correctly explained) to be badly designed and of=20 > limited utility in implementation. >=20 > -- > dean, wearing his paranoid I-told-you-so-and-I'm-not-acing-like-a- > chair hat. >=20 >=20 >=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 Wed Oct 25 15:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcoWp-0002Ns-Lk; Wed, 25 Oct 2006 15:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcoWo-0002Mg-V9 for sip@ietf.org; Wed, 25 Oct 2006 15:35:06 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcoWm-000514-F3 for sip@ietf.org; Wed, 25 Oct 2006 15:35:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PJZ1S6016591; Wed, 25 Oct 2006 22:35:02 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 22:34:47 +0300 Received: from [10.162.252.118] ([10.162.252.118]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Oct 2006 22:34:46 +0300 Message-ID: <453FBC55.3040903@nokia.com> Date: Wed, 25 Oct 2006 22:34:45 +0300 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Sip] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc References: <62B9B0847CC47543B6B3B5E26BD268E60E74621B@zrc2hxm2.corp.nortel.com> <450AB7A9.7070600@cisco.com> In-Reply-To: <450AB7A9.7070600@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 19:34:46.0322 (UTC) FILETIME=[A0B83120:01C6F86C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 ext Paul Kyzivat kirjoitti: >> Refer the following from section 10.2.1 of 3261 >> "A SIP UA can choose to register telephone numbers (with the tel URL, >> RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as >> Contacts for an address-of-record, for example." > > I have some sympathy for this. I think we get wound up thinking that the > contacts being registered are in fact destinations belonging to the UAC > doing the REGISTER. While this is usually the case, it need not always > be the case. I've seen SIP/3.0 mentioned here a few times, so here's my contribution to that end. I think it was a mistake to give REGISTER this dual meaning. i think we are in fact talking about two very different functions. 1) LOGIN by which a UA connects to the system (using sip-outbound) for being able to send requests outside (and having the system sign them with SIP idnetity) and receive requests inbound. 2) ALIAS by which another agent, perhaps acting for the AOR in some capacity, registers (ok, could be called REGISTER, too) another means of contacting the principal that owns the SIP AoR. Why I think these should be clearly separate methods is that the authorization decisions and the routing logic associated with them are vastly different. 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 Oct 25 15:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcohv-0002rc-H3; Wed, 25 Oct 2006 15:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcohu-0002rX-MI for sip@ietf.org; Wed, 25 Oct 2006 15:46:34 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcoht-0007A5-6l for sip@ietf.org; Wed, 25 Oct 2006 15:46:34 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PJkFof009847; Wed, 25 Oct 2006 22:46:23 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 22:46:14 +0300 Received: from [10.162.252.118] ([10.162.252.118]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Oct 2006 22:46:13 +0300 Message-ID: <453FBF04.6050204@nokia.com> Date: Wed, 25 Oct 2006 22:46:12 +0300 From: Aki Niemi Organization: Nokia-NRC/Helsinki User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: ext Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DB775C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DB775C8@zrc2hxm0.corp.nortel.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 19:46:13.0243 (UTC) FILETIME=[3A2804B0:01C6F86E] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes , 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 ext Francois Audet kirjoitti: > So, to summarize, you are NOT happy with the current consensus, and you > are proposing something completely different, i.e., that instead of just > the current cludgy "last-hop exception rule", we also add a new > "first-hop > exception" (and I would imagine a new "any hop exception" rule)? My recollection of at least the bar bof in Montreal was that we forget Contact altogether. That's what most registrars already do, because of all the crap (stunned addresses, private IPs, public IPs with restrictive FWs and so on) that UAs put there making it simply not reliable enough to be useful for anything. Therefore, I'd say if you want to receive requests securely, register via TLS and use sip-outbound. Now I don't know what that means in terms of the "last-hop exception", but IMHO, sips to me is usable only in terms of pointing me to a host and port where I can start a TLS session. If we had STARTTLS in SIP, I would not need sips. So I guess I agree with what Dean is saying. 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 Oct 25 15:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcols-0004Tu-RQ; Wed, 25 Oct 2006 15:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcolH-0003nL-D1; Wed, 25 Oct 2006 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcolG-0007ot-Ri; Wed, 25 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9D33D26E51; Wed, 25 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolG-0004oc-C7; Wed, 25 Oct 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: Wed, 25 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-05.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 : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-05.txt Pages : 39 Date : 2006-10-25 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-05.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-outbound-05.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-outbound-05.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-10-25111800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25111800.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 Wed Oct 25 16:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpRO-00034G-UL; Wed, 25 Oct 2006 16:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcomk-0005jK-59; Wed, 25 Oct 2006 15:51:34 -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 1Gcomk-0008CQ-2R; Wed, 25 Oct 2006 15:51:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gcomj-00065o-MS; Wed, 25 Oct 2006 15:51:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0B6342ACD5; Wed, 25 Oct 2006 19:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolH-0004rJ-Pe; Wed, 25 Oct 2006 15:50:03 -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: Wed, 25 Oct 2006 15:50:03 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-certs-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 : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-certs-02.txt Pages : 29 Date : 2006-10-25 This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-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-certs-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-certs-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-10-25124320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25124320.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 Wed Oct 25 17:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcq6O-0001HI-TQ; Wed, 25 Oct 2006 17:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcq6M-0001Gw-Qp for sip@ietf.org; Wed, 25 Oct 2006 17:15:54 -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 1Gcq6A-0006AB-Fp for sip@ietf.org; Wed, 25 Oct 2006 17:15:54 -0400 Received: from [172.17.1.75] ([172.17.1.75]) (authenticated bits=0) by vicuna.estacado.net (8.13.8/8.13.8) with ESMTP id k9PLFYfO093740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Oct 2006 16:15:35 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <453F6435.4040405@ericsson.com> References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A458EB7-4463-412F-B66C-9B645DB7D0F3@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Wed, 25 Oct 2006 16:15:29 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Sip List , Dean Willis Subject: [Sip] Consent-Framework: Store and Forward (was Re: WGLC comments for draft-ietf-sip-consent-framework-00) X-BeenThere: sip@ietf.org X-Mailman-Version: 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 separating my response about the consent-framework store and forward issue from the other issues, since I think this one needs more discussion. Specific's inline On Oct 25, 2006, at 8:18 AM, Gonzalo Camarillo wrote: [...] >> 4.3 >>> There are several mechanisms to implement store-and-forward message >>> services (e.g., with an instant message to email gateway). Any of >>> these mechanisms can be used between a user agent and its >>> store-and- forward server as long as they agree on which mechanism >>> to use. Therefore, this framework does not make any recommendation >>> on the interface between user agents and their store-and-forward >>> servers. >> It is not clear to me if store-and-forward servers are a required >> (i.e. normative) part of the consent architecture, or if they are >> just something that might exist. I infer the first, considering the >> draft always assumes the existence of them, and there are clear >> issues about handling permissions when you can't get a MESSAGE to the >> recipient. >> If we are going to normatively require them, then I have some >> heartburn about the fact that there is no specification of how they >> work. I don't expect _this_ doc to specify that, but it should be >> somewhere. In particular, if we are going to architecturally require >> them, we as a community should be concerned about interoperability >> between S&F servers and arbitrary UAs, which this document >> _explicitly_ punts on. > > yes, I agree a clarification is needed. I propose to add the following > text at the end of Section 4.3: > > NEW TEXT: > > Even though store-and-forward servers perform a useful function and > they are expected to be deployed in most domains, some domains will > not deploy them from day one. However, user agents and relays in > domains without store-and-forward servers can still use this > consent > framework, although with some limitations. In particular, > relays in > these domains are not able to request permissions from users > that are > off-line. > I'm still uncomfortable with this. The proposed text still implies that S&F servers are needed for a "complete" consent-framework solution, and that the framework essentially fails without them. 1) Specify consent-framework behavior from the assumption that no such thing exists, at least in the common case. That is, talk in some detail about what you do when the MESSAGE requests fail, and whether you should retry later, how often to retry, etc. We could point out that if an S&F type server were present, then an offline target should not cause the MESSAGE request to fail, but that would be about all we could say about them. 2) Recognize that the consent-framework has an architectural dependency on S&F servers, and have one of the related WGs go down the path of specifying one, to be normatively referenced here. I realize that option 2 is not a tenable solution, as it would block progress on the consent-framework for some time. My opinion is that we should go with option 1. If at some time in the future we standardize an S&F server, we could discuss their use in more detail in a separate 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 Wed Oct 25 17:32:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqKo-000112-1v; Wed, 25 Oct 2006 17:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpt2-0002kS-In for sip@ietf.org; Wed, 25 Oct 2006 17:02:08 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcpoo-0008CP-DH for sip@ietf.org; Wed, 25 Oct 2006 16:58:06 -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 k9PKdBb14013; Wed, 25 Oct 2006 16:39:11 -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] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Date: Wed, 25 Oct 2006 15:38:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DB777BC@zrc2hxm0.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20061025070044.03374e98@stevecrocker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Thread-Index: Acb4JTZrhS/p4x9ZSIGBDbnw8dD51AAUDz8Q From: "Francois Audet" To: "Joel M. Halpern" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 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 is certainly not what RFC 3261 says. What you are describing is more analogous to using TLS on a first hop=20 with sip (instead of sips).=20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Wednesday, October 25, 2006 4:03 AM > To: Dean Willis; Audet, Francois (SC100:3055) > Cc: Adam Roach; Robert Sparks; Paul Kyzivat; Gonzalo=20 > Camarillo; IETF SIP List; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC:=20 > draft-ietf-sipping-dialogusage-03.txt) >=20 > I have tried to say this before. > SIPS is frequently (I was going to say normally, but I don't=20 > think anything in this situation is normal) understood to=20 > mean "SIP with Security". And because SIP is much like=20 > Email, I tend to think of it as very parallel to the use of=20 > iMAPS / POPS on the first leg, and then whatever happens to=20 > get used thereafter. > I like the fact that as distinct from email SIPS does=20 > actually request that later hops provide security. >=20 > Yours, > Joel M. Halpern >=20 > PS: Sorry, I don't know why there is such a duplicated list=20 > of people, so I am not trimming the dups. >=20 > At 01:01 AM 10/25/2006, Dean Willis wrote: > >But SMTP, which uses a hop-by-hop relayance model much more=20 > similar to=20 > >SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop=20 > >security, because that would just be silly for email (as it is silly=20 > >for SIP, from a security perspective). > > > >But if you ask somebody (outside this small group) what the trailing=20 > >"S" on all those protocols means, they'll probably say it means=20 > >"secure". >=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 Wed Oct 25 17:35:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqNH-0001pw-58; Wed, 25 Oct 2006 17:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcpFN-0007YK-Hv for sip@ietf.org; Wed, 25 Oct 2006 16:21:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcp2P-00037M-Eb for sip@ietf.org; Wed, 25 Oct 2006 16:08:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Oct 2006 16:07:45 -0400 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 k9PK7jYf007188; Wed, 25 Oct 2006 16:07: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 k9PK7jDO014669; Wed, 25 Oct 2006 16:07: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, 25 Oct 2006 16:07:45 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:07:44 -0400 Message-ID: <453FC410.2000505@cisco.com> Date: Wed, 25 Oct 2006 16:07:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc References: <62B9B0847CC47543B6B3B5E26BD268E60E74621B@zrc2hxm2.corp.nortel.com> <450AB7A9.7070600@cisco.com> <453FBC55.3040903@nokia.com> In-Reply-To: <453FBC55.3040903@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 20:07:44.0513 (UTC) FILETIME=[3BD02F10:01C6F871] DKIM-Signature: a=rsa-sha1; q=dns; l=2688; t=1161806865; x=1162670865; 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]=20Another=20Comment=20on=20draft-audet-sip-sips-guidelines -03=20w.r.t.=0A=20telURI=20etc |To:Aki=20Niemi=20; X=v=3Dcisco.com=3B=20h=3DG3nwNVsZEIl4pIHAtSs3sHxQlPs=3D; b=kPXVU0aAYU4Ft2kUNSI742r3uAgPXp66diSeycfNiK8SsDEUDxYcgULr00lx3QHr24IODkmW CuMXKXmTnF0ji8HtJ06dpud3xDi+H9SGDBmYsVmK6s8na3QnFDoMB5P/; 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: e8a67952aa972b528dd04570d58ad8fe 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, I don't know whether to agree or disagree. You seem to be suggesting that *something* ought to be different in SIP/3.0 because we got it wrong in 2.0. But I'm not sure which part we got wrong. (I agree that it seems that *something* is wrong.) Unfortunately, I don't think that now is the time to be talking about SIP/3.0. That would be a good way to ensure the total demise of SIP. In the "if I were starting over I would do it differently" category, I have recently been thinking along somewhat similar lines. In particular I've been thinking that for NAT/FW, lack of certs, etc. (all sorts of things where the UA lacks capabilities it needs to fully participate) it would have been better for it to latch up to some "agent" that has all those things and can act on its behalf in all ways. This would be a B2BUA, and possibly a TURN server. Its would be something like an SBC or a P-CSCF, but it would work on behalf of the UA, not the "provider". From the point of view of everybody else, this "agent" would be the UA. That would leave the basic sip stuff more "pristine", and leave the fixups to this one relationship. But that is just idle thought. I don't see how we can turn the clock back. Paul Aki Niemi wrote: > > > ext Paul Kyzivat kirjoitti: >>> Refer the following from section 10.2.1 of 3261 >>> "A SIP UA can choose to register telephone numbers (with the tel URL, >>> RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as >>> Contacts for an address-of-record, for example." >> I have some sympathy for this. I think we get wound up thinking that the >> contacts being registered are in fact destinations belonging to the UAC >> doing the REGISTER. While this is usually the case, it need not always >> be the case. > > I've seen SIP/3.0 mentioned here a few times, so here's my contribution > to that end. > > I think it was a mistake to give REGISTER this dual meaning. i think we > are in fact talking about two very different functions. > > 1) LOGIN by which a UA connects to the system (using sip-outbound) for > being able to send requests outside (and having the system sign them > with SIP idnetity) and receive requests inbound. > > 2) ALIAS by which another agent, perhaps acting for the AOR in some > capacity, registers (ok, could be called REGISTER, too) another means of > contacting the principal that owns the SIP AoR. > > Why I think these should be clearly separate methods is that the > authorization decisions and the routing logic associated with them are > vastly different. > > 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 Oct 25 17:42:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqUA-0004SW-2U; Wed, 25 Oct 2006 17:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcptF-0002kx-OR for sip@ietf.org; Wed, 25 Oct 2006 17:02:21 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpmC-0007LF-1v for sip@ietf.org; Wed, 25 Oct 2006 16:55:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PKS3Tf020201; Wed, 25 Oct 2006 23:28:07 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 23:27:03 +0300 Received: from [10.162.252.118] ([10.162.252.118]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Oct 2006 23:27:03 +0300 Message-ID: <453FC896.8060403@nokia.com> Date: Wed, 25 Oct 2006 23:27:02 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5.0.7 (X11/20060918) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Sip] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc References: <62B9B0847CC47543B6B3B5E26BD268E60E74621B@zrc2hxm2.corp.nortel.com> <450AB7A9.7070600@cisco.com> <453FBC55.3040903@nokia.com> <453FC410.2000505@cisco.com> In-Reply-To: <453FC410.2000505@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2006 20:27:03.0759 (UTC) FILETIME=[EEC715F0:01C6F873] 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Paul Kyzivat kirjoitti: > In the "if I were starting over I would do it differently" category, I > have recently been thinking along somewhat similar lines. In particular > I've been thinking that for NAT/FW, lack of certs, etc. (all sorts of > things where the UA lacks capabilities it needs to fully participate) it > would have been better for it to latch up to some "agent" that has all > those things and can act on its behalf in all ways. This would be a > B2BUA, and possibly a TURN server. Its would be something like an SBC or > a P-CSCF, but it would work on behalf of the UA, not the "provider". > From the point of view of everybody else, this "agent" would be the UA. I think we're definitely headed that way already with outbound, identity and others. I think it's mainly the NAT problematics that makes most UAs unable to participate to the system unless they "login" at an agent and use the same transport for all further communications. > That would leave the basic sip stuff more "pristine", and leave the > fixups to this one relationship. Or perhaps another way to put it is that there are separate UNI and NNI in SIP. Or c2s and s2s as XMPP puts it, I think. 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 Oct 25 17:45:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqWp-00068B-1S; Wed, 25 Oct 2006 17:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpsw-0002iK-OQ for sip@ietf.org; Wed, 25 Oct 2006 17:02:02 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpqI-0008Rk-Ia for sip@ietf.org; Wed, 25 Oct 2006 16:59:35 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3C2101E8C28; Wed, 25 Oct 2006 13:59:15 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> From: Eric Rescorla Date: Wed, 25 Oct 2006 13:59:15 -0700 In-Reply-To: <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> (Rohan Mahy's message of "Wed, 25 Oct 2006 13:00:23 -0700") Message-ID: <86lkn4qfh8.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: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List 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 "Rohan Mahy" writes: > On 10/24/06, EKR wrote: >> "Rohan Mahy" writes: >> > On 10/23/06, Jonathan Rosenberg wrote: >> >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is >> >> assigned when you first register a contact, and an additional one is >> >> created on each refresh. All of the ones accumulated over the >> >> lifetime of the registration remain valid. Each of them obfuscate >> >> the AOR and instance ID. Added a description of a stateless >> >> algorithm for computing these. Lengthy discussion on the privacy >> >> implications of using them. >> > >> > I just reviewed the extremely lengthy thread on GRUU privacy and have >> > yet to see anything resembling consensus on which privacy or >> > limited-user requirements we are trying to add here. >> >> I'm not sure I agree with this assertion, but I certainly >> don't think there was consensus on *not* including some >> privacy mechanisms. > > Actually there was such a consensus when we took the requirements and > formally handed them to SIP. Maybe so, but there's not now, and now is what's important for assessing WG consensus on moving a document forward. >> > Furthermore I >> > expect that the mechanism provided could be abused by UAs that want a >> > private per call for example, creating a lot of registration thrash, >> > jeopardizing the avalanche restart prevention work in outbound. >> >> I don't understand what the security problem you're concerned with >> is. Can you describe the scenario in more detail? > > Its not a security problem. It is an operational problem. A user > agent that fetches new gruu for every new call would add a substantial > amount of additional load on a registrar, especially if that registrar > was also doing outbound processing. I don't see that. Why? -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 Oct 25 17:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqdC-0001ED-QW; Wed, 25 Oct 2006 17:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpsq-0002cs-4t for sip@ietf.org; Wed, 25 Oct 2006 17:01:56 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpsB-0000O1-EQ for sip@ietf.org; Wed, 25 Oct 2006 17:01:25 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F06BE1E8C28; Wed, 25 Oct 2006 14:01:14 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] New I-D on UA loose routing References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> From: Eric Rescorla Date: Wed, 25 Oct 2006 14:01:14 -0700 In-Reply-To: <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> (Rohan Mahy's message of "Wed, 25 Oct 2006 12:57:37 -0700") Message-ID: <86fydcqfdx.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: IETF SIP List 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 "Rohan Mahy" writes: > On 10/24/06, EKR wrote: >> Rohan Mahy wrote: >> > I have read this draft and I think it is a terrible idea in SIP/2.0 to >> > send a UA an incoming request with a Route header. If we were working >> > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea >> > to consider as baseline behavior, but I think this is too major of a >> > change from the current spec and state of implementation. >> > >> > Lets analyze the requirements described in the document. The unkown >> > gruu, limited-use gruu, subaddressing, and service invocation >> > requirements can all be met just by restoring the grid parameter to >> > its rightful place in GRUU. >> >> Not really, no. You'd like to be able to generate limited-use addresses >> that point to the AOR, not the GRUU. This is reflective of the basic >> problem: attaching disambiguators to a SIP URI is something that >> should be done generically, not confined to GRUU. > > If you are proposing a new parameter that proxies should copy through > to a user agent, that would be fine with me, but doing that would be a > new extension and would require proxies to implement it. You could > call it grid or you could call it something else. The general > property you describe however would not require UAs to handle incoming > requests with Route headers. Right, that's just one way of implementing. My point in responding to your message was that a parameter that is GRUU-only to do a task that is applicable outside of GRUU is a Bad Thing. -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 Oct 25 17:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcqjG-0004yy-4L; Wed, 25 Oct 2006 17:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcptY-0002kv-2j for sip@ietf.org; Wed, 25 Oct 2006 17:02:40 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcpkY-0006oR-93 for sip@ietf.org; Wed, 25 Oct 2006 16:53:25 -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 k9PKkYh29395; Wed, 25 Oct 2006 16:46:34 -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] RE: TLS meaning Date: Wed, 25 Oct 2006 15:53:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DB7781C@zrc2hxm0.corp.nortel.com> In-Reply-To: <453FBF04.6050204@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb4bknPtkpcnwpMTyuTM2dUglmU/gACP9VQ From: "Francois Audet" To: "Aki Niemi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 =20 > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com]=20 > Sent: Wednesday, October 25, 2006 12:46 PM > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; Adam Roach; Robert Sparks; Paul Kyzivat;=20 > Gonzalo Camarillo; IETF SIP List; Barnes, Mary (RICH2:AR00) > Subject: Re: [Sip] RE: TLS meaning > My recollection of at least the bar bof in Montreal was that=20 > we forget Contact altogether. That's what most registrars=20 > already do, because of all the crap (stunned addresses,=20 > private IPs, public IPs with restrictive FWs and so on) that=20 > UAs put there making it simply not reliable enough to be=20 > useful for anything. Agreed. > Therefore, I'd say if you want to receive requests securely,=20 > register via TLS and use sip-outbound. Agreed again. > Now I don't know what that means in terms of the "last-hop=20 > exception", but IMHO, sips to me is usable only in terms of=20 > pointing me to a host and port where I can start a TLS=20 > session. If we had STARTTLS in SIP, I would not need sips. Sure. > So I guess I agree with what Dean is saying. You completely lost me here. Dean is basically saying that sips should be able to mean other protocols than TLS (e.g., IPsec). So pretty much the opposite of your points in this email. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 17:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqk6-0005a6-OI; Wed, 25 Oct 2006 17:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqk5-0005ZE-Pp for sip@ietf.org; Wed, 25 Oct 2006 17:56:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcqjz-0007nc-G7 for sip@ietf.org; Wed, 25 Oct 2006 17:56:57 -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 k9PLulb07439; Wed, 25 Oct 2006 17:56:47 -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] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc Date: Wed, 25 Oct 2006 16:56:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DB77939@zrc2hxm0.corp.nortel.com> In-Reply-To: <453FC896.8060403@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc Thread-Index: Acb4fm186T82AQBOROqY7anoXqMiSAAAe+hw From: "Francois Audet" To: "Aki Niemi" , "ext Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 =20 > I think we're definitely headed that way already with=20 > outbound, identity and others. I think it's mainly the NAT=20 > problematics that makes most UAs unable to participate to the=20 > system unless they "login" at an agent and use the same=20 > transport for all further communications. Agree. > > That would leave the basic sip stuff more "pristine", and leave the=20 > > fixups to this one relationship. >=20 > Or perhaps another way to put it is that there are separate=20 > UNI and NNI in SIP. Or c2s and s2s as XMPP puts it, I think. Outch... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 18:06:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqqh-0000Js-6q; Wed, 25 Oct 2006 18:03:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcqqe-0000JQ-TK for sip@ietf.org; Wed, 25 Oct 2006 18:03:44 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcqqc-00005T-BA for sip@ietf.org; Wed, 25 Oct 2006 18:03:44 -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 k9PM3cb15663; Wed, 25 Oct 2006 18:03: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] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc Date: Wed, 25 Oct 2006 17:03:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DB77960@zrc2hxm0.corp.nortel.com> In-Reply-To: <453FC410.2000505@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Another Comment on draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc Thread-Index: Acb4fWErp2HHJRgSQvC4QapHn/k18gAAzHog From: "Francois Audet" To: "Paul Kyzivat" , "Aki Niemi" 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 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, October 25, 2006 1:08 PM > To: Aki Niemi > Cc: sip@ietf.org > Subject: Re: [Sip] Another Comment on=20 > draft-audet-sip-sips-guidelines-03 w.r.t. telURI etc >=20 > Aki, >=20 > I don't know whether to agree or disagree. You seem to be=20 > suggesting that *something* ought to be different in SIP/3.0=20 > because we got it wrong in 2.0. But I'm not sure which part=20 > we got wrong. (I agree that it seems that *something* is wrong.) >=20 > Unfortunately, I don't think that now is the time to be=20 > talking about SIP/3.0. That would be a good way to ensure the=20 > total demise of SIP. The assumption/directiveve in the draft-audet-sip-sips-guidelines document is that we are NOT talking SIP 3.0, but the current RFC 3261, potentially with some corrections when absolutely necessary. It tought it was pretty clear from Montreal that this is what we agreed to. That's kind of what I'm saying in my reply to Dean. If security was to be redone (with SIP 3.0 for example), I don't think=20 we would define a secure URI scheme like sips for one thing. And I=20 certainly don't think we would tie security to a single security=20 mechanism (TLS or otherwise). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 25 20:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcskA-0006YW-0b; Wed, 25 Oct 2006 20:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcsk9-0006Uy-7s for sip@ietf.org; Wed, 25 Oct 2006 20:05:09 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcsk7-0008D3-Tj for sip@ietf.org; Wed, 25 Oct 2006 20:05:09 -0400 Received: by ug-out-1314.google.com with SMTP id 72so218222ugd for ; Wed, 25 Oct 2006 17:05:07 -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=Bdoa8hrAohP/A3uBdy8c0Yg+jv298nXIwBREUt6LEq+b4RE4KWih+nyCm+X/cDtMqaWdndLv/BTtdGZHX2D1C1ZL7TDdQuKsKW5BXwtykrO3zaHCV2F18tRY0AycYM87KmxlToa4DuEAYD4KxJj0mSf6Z26RyHecPISc9zAxzAA= Received: by 10.78.94.37 with SMTP id r37mr724676hub; Wed, 25 Oct 2006 17:05:06 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Wed, 25 Oct 2006 17:05:06 -0700 (PDT) Message-ID: <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> Date: Wed, 25 Oct 2006 17:05:06 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <86lkn4qfh8.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> <86lkn4qfh8.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 10/25/06, Eric Rescorla wrote: > "Rohan Mahy" writes: > > > On 10/24/06, EKR wrote: > >> "Rohan Mahy" writes: > >> > On 10/23/06, Jonathan Rosenberg wrote: > >> >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is > >> >> assigned when you first register a contact, and an additional one is > >> >> created on each refresh. All of the ones accumulated over the > >> >> lifetime of the registration remain valid. Each of them obfuscate > >> >> the AOR and instance ID. Added a description of a stateless > >> >> algorithm for computing these. Lengthy discussion on the privacy > >> >> implications of using them. > >> > > >> > I just reviewed the extremely lengthy thread on GRUU privacy and have > >> > yet to see anything resembling consensus on which privacy or > >> > limited-user requirements we are trying to add here. > >> > >> I'm not sure I agree with this assertion, but I certainly > >> don't think there was consensus on *not* including some > >> privacy mechanisms. > > > > Actually there was such a consensus when we took the requirements and > > formally handed them to SIP. > > Maybe so, but there's not now, and now is what's important for > assessing WG consensus on moving a document forward. I do not see any consensus around privacy requirements. I'm not saying that one does not exist, or one cannot be forged. However, we consciously decided to postpone additional privacy work when we started GRUU. I don't see what has suddenly changed so that we have to cram a possibly half-assed mechanism into the GRUU spec. > >> > Furthermore I > >> > expect that the mechanism provided could be abused by UAs that want a > >> > private per call for example, creating a lot of registration thrash, > >> > jeopardizing the avalanche restart prevention work in outbound. > >> > >> I don't understand what the security problem you're concerned with > >> is. Can you describe the scenario in more detail? > > > > Its not a security problem. It is an operational problem. A user > > agent that fetches new gruu for every new call would add a substantial > > amount of additional load on a registrar, especially if that registrar > > was also doing outbound processing. > > I don't see that. Why? A registrar sized to handle x UAs with an average of just over 2 registrations per hour suddenly finds a non-trivial number of its UAs registering 10, 20, or 50 times during the busiest period. thx, -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 Oct 25 20:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsmJ-0000Ds-Ul; Wed, 25 Oct 2006 20:07:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcsmI-0000CV-SX for sip@ietf.org; Wed, 25 Oct 2006 20:07:22 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcsmH-0000Bd-I8 for sip@ietf.org; Wed, 25 Oct 2006 20:07:22 -0400 Received: by nf-out-0910.google.com with SMTP id n15so773277nfc for ; Wed, 25 Oct 2006 17:07:20 -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=QzPECsohk/G77aEsEGFbH3iuV3wTNTHvYymxuu3QBkxyoCUWxBOyVFCl8hE6bNjClruMXNL44yfiEVPyoRwC4Rc+lAlzLe+FSdP000zADgcolzXuR3qo1zcvJ4shWJ/36d1/xjyJHblZMLIkL4RpAMbhIt9kLH6cEaxilihMY+Q= Received: by 10.78.201.8 with SMTP id y8mr731421huf; Wed, 25 Oct 2006 17:07:20 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Wed, 25 Oct 2006 17:07:20 -0700 (PDT) Message-ID: <953beacc0610251707j5777516bsa6551ca494d5f91b@mail.gmail.com> Date: Wed, 25 Oct 2006 17:07:20 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <86fydcqfdx.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> <86fydcqfdx.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 10/25/06, Eric Rescorla wrote: > "Rohan Mahy" writes: > > > On 10/24/06, EKR wrote: > >> Rohan Mahy wrote: > >> > I have read this draft and I think it is a terrible idea in SIP/2.0 to > >> > send a UA an incoming request with a Route header. If we were working > >> > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea > >> > to consider as baseline behavior, but I think this is too major of a > >> > change from the current spec and state of implementation. > >> > > >> > Lets analyze the requirements described in the document. The unkown > >> > gruu, limited-use gruu, subaddressing, and service invocation > >> > requirements can all be met just by restoring the grid parameter to > >> > its rightful place in GRUU. > >> > >> Not really, no. You'd like to be able to generate limited-use addresses > >> that point to the AOR, not the GRUU. This is reflective of the basic > >> problem: attaching disambiguators to a SIP URI is something that > >> should be done generically, not confined to GRUU. > > > > If you are proposing a new parameter that proxies should copy through > > to a user agent, that would be fine with me, but doing that would be a > > new extension and would require proxies to implement it. You could > > call it grid or you could call it something else. The general > > property you describe however would not require UAs to handle incoming > > requests with Route headers. > > Right, that's just one way of implementing. My point in responding to your > message was that a parameter that is GRUU-only to do a task that is > applicable outside of GRUU is a Bad Thing. Postponing this *agreed-upon* functionality for GRUU to depend on a brand-new untested mechanism is a MUCH WORSE Thing. 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 Wed Oct 25 20:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcso2-0002AB-TS; Wed, 25 Oct 2006 20:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcso0-00027r-3Y for sip@ietf.org; Wed, 25 Oct 2006 20:09: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 1GcpWf-0003V5-An for sip@ietf.org; Wed, 25 Oct 2006 16:39:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcpFy-0008U8-QC for sip@ietf.org; Wed, 25 Oct 2006 16:21:48 -0400 Received: by ug-out-1314.google.com with SMTP id 72so176633ugd for ; Wed, 25 Oct 2006 13:21:44 -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=XpVg0/O0YqSQlbJ8t/j8qtiFKcm2Pgr9hrVLSxV0IzXONdQOA8MkbscY6sfbckzHt91VOMKDuaU40Jp5Fg5eQsc9FqO/yuYlW/t6owsMZOntKWcZRxKFzNEhkbLPMjqVA8JXEV5XN7nWFaE1riDcDhSTQRso+KL5OQcwbD0FUKw= Received: by 10.78.157.8 with SMTP id f8mr1019156hue; Wed, 25 Oct 2006 12:57:37 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Wed, 25 Oct 2006 12:57:37 -0700 (PDT) Message-ID: <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> Date: Wed, 25 Oct 2006 12:57:37 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <20061025002453.B63121CC5D@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 10/24/06, EKR wrote: > Rohan Mahy wrote: > > I have read this draft and I think it is a terrible idea in SIP/2.0 to > > send a UA an incoming request with a Route header. If we were working > > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea > > to consider as baseline behavior, but I think this is too major of a > > change from the current spec and state of implementation. > > > > Lets analyze the requirements described in the document. The unkown > > gruu, limited-use gruu, subaddressing, and service invocation > > requirements can all be met just by restoring the grid parameter to > > its rightful place in GRUU. > > Not really, no. You'd like to be able to generate limited-use addresses > that point to the AOR, not the GRUU. This is reflective of the basic > problem: attaching disambiguators to a SIP URI is something that > should be done generically, not confined to GRUU. If you are proposing a new parameter that proxies should copy through to a user agent, that would be fine with me, but doing that would be a new extension and would require proxies to implement it. You could call it grid or you could call it something else. The general property you describe however would not require UAs to handle incoming requests with Route headers. 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 Wed Oct 25 21:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gctcd-0006aR-OB; Wed, 25 Oct 2006 21:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gctcc-0006aL-Pd for sip@ietf.org; Wed, 25 Oct 2006 21:01:26 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gctcb-00017H-Fr for sip@ietf.org; Wed, 25 Oct 2006 21:01:26 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F04691E8C28; Wed, 25 Oct 2006 18:01:24 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] New I-D on UA loose routing References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> <86fydcqfdx.fsf@raman.networkresonance.com> <953beacc0610251707j5777516bsa6551ca494d5f91b@mail.gmail.com> From: Eric Rescorla Date: Wed, 25 Oct 2006 18:01:24 -0700 In-Reply-To: <953beacc0610251707j5777516bsa6551ca494d5f91b@mail.gmail.com> (Rohan Mahy's message of "Wed, 25 Oct 2006 17:07:20 -0700") Message-ID: <86y7r3q49n.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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List 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 "Rohan Mahy" writes: > On 10/25/06, Eric Rescorla wrote: >> Right, that's just one way of implementing. My point in responding to your >> message was that a parameter that is GRUU-only to do a task that is >> applicable outside of GRUU is a Bad Thing. > > Postponing this *agreed-upon* functionality for GRUU to depend on a > brand-new untested mechanism is a MUCH WORSE Thing. I don't agree, but I think we're talking past each other here. Prior to this change GRUU defined a mechanism whereby the UAC could add a disambiguator to a GRUU. My point is that whatever mechanism we choose should have applicability outside of GRUU. Are you objecting to this? If so, why? I appreciate that you think the particular proposed mechanism to attack this problem is bad, but that's not what I'm arguing for here... -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 Oct 25 21:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GctiC-0007qA-8g; Wed, 25 Oct 2006 21:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GctiB-0007px-1l for sip@ietf.org; Wed, 25 Oct 2006 21:07:11 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcti7-0002CO-NO for sip@ietf.org; Wed, 25 Oct 2006 21:07:11 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3BC691E8C29; Wed, 25 Oct 2006 18:07:07 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> <86lkn4qfh8.fsf@raman.networkresonance.com> <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> From: Eric Rescorla Date: Wed, 25 Oct 2006 18:07:07 -0700 In-Reply-To: <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> (Rohan Mahy's message of "Wed, 25 Oct 2006 17:05:06 -0700") Message-ID: <86odrzq404.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: IETF SIP List 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 "Rohan Mahy" writes: > On 10/25/06, Eric Rescorla wrote: > I do not see any consensus around privacy requirements. I'm not > saying that one does not exist, or one cannot be forged. However, we > consciously decided to postpone additional privacy work when we > started GRUU. I don't see what has suddenly changed so that we have > to cram a possibly half-assed mechanism into the GRUU spec. What's changed is that a lot of people came to the conclusion that GRUU as-was represented a serious privacy threat. >> I don't see that. Why? > > A registrar sized to handle x UAs with an average of just over 2 > registrations per hour suddenly finds a non-trivial number of its UAs > registering 10, 20, or 50 times during the busiest period. I'm having a little trouble understanding your arrival model here. In what environment, exactly, are people having to get 50 anonymous GRUUs in a short period of time? -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 Oct 25 23:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcw2m-0007sS-1I; Wed, 25 Oct 2006 23:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcw2k-0007s6-Dv for sip@ietf.org; Wed, 25 Oct 2006 23:36:34 -0400 Received: from mail.zte.com.cn ([202.103.147.144] helo=Riskfilter2.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcw2g-0007sF-IB for sip@ietf.org; Wed, 25 Oct 2006 23:36:34 -0400 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 83345.1112621526; Thu, 26 Oct 2006 12:00:17 +0800 (CST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: zhang.lu2@zte.com.cn Date: Thu, 26 Oct 2006 11:35:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-10-26 11:36:18, Serialize complete at 2006-10-26 11:36:18 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Sip] Help: About Early-Session and Session X-BeenThere: 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="===============1126676543==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1126676543== Content-Type: multipart/alternative; boundary="=_alternative 0013C7E148257213_=" This is a multipart message in MIME format. --=_alternative 0013C7E148257213_= Content-Type: text/plain; charset="US-ASCII" Dear Sip Group, There encounters a question when I read RFC 3959 and RFC 3960 which refer to the Early-Session , that is "Does Offer/Answer Model defined in RFC 3264 apply to Early-Session and Session independently?" In RFC 3959 section 7, there is a example as below: A B | | |--------(1) INVITE-------->| | offer | | | |<--(2) Session Progress----| | early-offer | | answer | | | |---------(3) PRACK-------->| | early-answer | | | |<--------(4) 200 OK--------| | | | * * | | ************************* | |* Early Media *| | ************************* | | * * | | | |<--------(5) 200 OK--------| | | |----------(6) ACK--------->| | | Figure 1: Message flow Hope to have a letter from you soon. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0013C7E148257213_= Content-Type: text/html; charset="US-ASCII"
Dear Sip Group,

     There encounters a question when I read RFC 3959 and RFC 3960 which refer to the Early-Session , that is
   
       "Does Offer/Answer Model defined in RFC 3264 apply to Early-Session and Session independently?"

     In RFC 3959 section 7, there is a example as below:
      A                           B
      |                           |
      |--------(1) INVITE-------->|
      |            offer          |
      |                           |
      |<--(2) Session Progress----|
      |       early-offer         |
      |       answer              |
      |                           |
      |---------(3) PRACK-------->|
      |             early-answer  |
      |                           |
      |<--------(4) 200 OK--------|
      |                           |
      |  *                     *  |
      | ************************* |
      |*       Early Media       *|
      | ************************* |
      |  *                     *  |
      |                           |
      |<--------(5) 200 OK--------|
      |                           |
      |----------(6) ACK--------->|
      |                           |

          Figure 1: Message flow
         

    Hope to have a letter from you soon.

     
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0013C7E148257213_=-- --===============1126676543== 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 --===============1126676543==-- From sip-bounces@ietf.org Thu Oct 26 02:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcyVD-0000ve-R1; Thu, 26 Oct 2006 02:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcyVC-0000ty-KW for sip@ietf.org; Thu, 26 Oct 2006 02:14: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 1GcpXG-0003IX-PI for sip@ietf.org; Wed, 25 Oct 2006 16:39:38 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GcovQ-0006lW-Ic for sip@ietf.org; Wed, 25 Oct 2006 16:00:38 -0400 Received: by ug-out-1314.google.com with SMTP id 72so171165ugd for ; Wed, 25 Oct 2006 13:00:24 -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=FO2jdyDfTUed0cT66ekKL+0oNIcA866UQc35r0dQbqJaIgBEzqYtua0Y2zacei9dOMY9mbAeKUxpIWd/cVPuOrHP/J7go+jOGO/eQg1tpjQeaTPpFWnC/TPiDkz4oYaqEQoThYr2KxdcxQe7HK8o58XwpeTCVEzh4G74iT4arbI= Received: by 10.78.201.2 with SMTP id y2mr388099huf; Wed, 25 Oct 2006 13:00:23 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Wed, 25 Oct 2006 13:00:23 -0700 (PDT) Message-ID: <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> Date: Wed, 25 Oct 2006 13:00:23 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <86u01tdzxf.fsf@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 10/24/06, EKR wrote: > "Rohan Mahy" writes: > > On 10/23/06, Jonathan Rosenberg wrote: > >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is > >> assigned when you first register a contact, and an additional one is > >> created on each refresh. All of the ones accumulated over the > >> lifetime of the registration remain valid. Each of them obfuscate > >> the AOR and instance ID. Added a description of a stateless > >> algorithm for computing these. Lengthy discussion on the privacy > >> implications of using them. > > > > I just reviewed the extremely lengthy thread on GRUU privacy and have > > yet to see anything resembling consensus on which privacy or > > limited-user requirements we are trying to add here. > > I'm not sure I agree with this assertion, but I certainly > don't think there was consensus on *not* including some > privacy mechanisms. Actually there was such a consensus when we took the requirements and formally handed them to SIP. > > Furthermore I > > expect that the mechanism provided could be abused by UAs that want a > > private per call for example, creating a lot of registration thrash, > > jeopardizing the avalanche restart prevention work in outbound. > > I don't understand what the security problem you're concerned with > is. Can you describe the scenario in more detail? Its not a security problem. It is an operational problem. A user agent that fetches new gruu for every new call would add a substantial amount of additional load on a registrar, especially if that registrar was also doing outbound processing. 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 Thu Oct 26 03:27:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gczbc-0003mA-J4; Thu, 26 Oct 2006 03:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gczba-0003lq-UT for sip@ietf.org; Thu, 26 Oct 2006 03:24:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GczbR-000238-C1 for sip@ietf.org; Thu, 26 Oct 2006 03:24:46 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B2C57199; Thu, 26 Oct 2006 09:24:36 +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, 26 Oct 2006 09:24:33 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 09:24:30 +0200 Received: from [131.160.36.36] (EH3I2003TGFCPET-131160036036.lmf.ericsson.se [131.160.36.36]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D9C6824A8; Thu, 26 Oct 2006 10:24:29 +0300 (EEST) Message-ID: <454062AD.8060605@ericsson.com> Date: Thu, 26 Oct 2006 10:24:29 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Campbell References: <6081A75A-F7DF-441F-8003-B0CCF83C4D47@estacado.net> <453F6435.4040405@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 07:24:30.0303 (UTC) FILETIME=[C6C006F0:01C6F8CF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Sip List , Dean Willis Subject: [Sip] Re: WGLC comments for draft-ietf-sip-consent-framework-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Ben, >>> 6. IANA Considerations (editorial) Shouldn't we have some text or >>> a table showing where these new header fields are allowed? Also, >>> to show for which methods the 470 response is allowed.? >> >> My personal opinion is that those tables are typically out of date >> shortly after they are created and, thus, are useless most of the >> time. I would prefer not to add them. > > Do you object to the format or the content of such tables? many people complain that the format of those tables make them difficult to understand, but I was talking about their content. As soon as a new method o a new response code is created, those tables are typically out of date. Usually, it is enough if drafts explain header fields' restrictions using normative text. In any case, I do not think we need such tables for this particular draft. >> When store-and-forward servers are used, the interface between a >> user agent and its store-and-forward server may not be based on >> SIP. In such case, SIPS cannot be used to secure those URIs. It >> MUST be possible for store-and-forward servers to deliver encrypted >> and integrity-protected messages to their user agents. >> >> > > Can we put normative requirements on the piece of the architecture > that may or may not exist? This is sort of like pinning the tail on > the rumor of a donkey. My point was really that we need to document > that the security issue exists, depending on what these devices do, > rather than to state what they must do. I believe putting a requirement on the type of store and forward server that can be used with this framework is completely OK. However, if you would like to remove the normative MUST, we can do that. Feel free to edit the paragraph I proposed so that you are happy with it. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 06:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2F4-0003nM-Jm; Thu, 26 Oct 2006 06:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2EV-0002zY-Iq for sip@ietf.org; Thu, 26 Oct 2006 06:13:07 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2AA-00064U-Kp for sip@ietf.org; Thu, 26 Oct 2006 06:08:44 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9QA8YdP005912 for ; Thu, 26 Oct 2006 05:08:34 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Oct 2006 05:08:33 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Oct 2006 12:08:33 +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] Update to outbound draft: draft-ietf-sip-outbound-05 Date: Thu, 26 Oct 2006 12:08:32 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918069ACA1@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 thread-index: Acb3BuE8/yFN+ct4RIKvN26/63HjjAAhyG6QAFXmbAA= From: "Drage, Keith \(Keith\)" To: "sip" X-OriginalArrivalTime: 26 Oct 2006 10:08:33.0182 (UTC) FILETIME=[B1902BE0:01C6F8E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Please remember to read outbound and comment to the list. However the main purpose of this mail is to indicate that we intend to conduct a process similar to that currently in progress for GRUU to get it out of the door. Thus in parallel to revitalising the WGLC we will be seeking people who are actively working in this area to review the document and participate in review calls to resolve the issues. This is not an exclusive team, but we are actively looking for people who have or will be working with the document in IETF or in other SDOs, to people from outside SIP who need to do reviews (e.g. security) and to people who are implementing this stuff. We cannot guarantee when this will start (we do need to do it in the next meeting cycle). I will be trawling for people at IETF#67, but if you think you should be involved, don't make me come looking for you. Shout up, either by mail or coming up and saying hello. Even if you cannot commit the cycles to be on this team, all comments will be addressed and results made public - so please do not feel precluded from making comments in the normal fashion - i.e. to authors and list. Regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: 25 October 2006 00:03 > To: sip > Subject: RE: [Sip] Update to outbound draft:=20 > draft-ietf-sip-outbound-05 >=20 > Now we have finally got this document, I want you all to wind=20 > yourself back the discussions we were having three months ago. >=20 > Does this update reflect what you think you were discussing.=20 > If so say so on the list. If it doesn't then also say so on the list. >=20 > This has an agenda slot in IETF#67. I want to see the content=20 > of that agenda slot reflecting issues of current concern to the WG. >=20 > This work is meant to be high priority. It should be=20 > finished. It has been in WGLC for a long time. Let's work to=20 > get it out of the door. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan.mahy@gmail.com] > > Sent: 24 October 2006 01:49 > > To: sip > > Cc: Rohan Mahy > > Subject: [Sip] Update to outbound draft: draft-ietf-sip-outbound-05 > >=20 > > Hi Folks, > >=20 > > Yesterday I did an extremely belated, but very detailed update to=20 > > outbound. I believe that I have incorporated all the changes we=20 > > discussed at the Montreal meeting and the consenus reached on the=20 > > mailing list regarding STUN. I also incorporated a new=20 > short section=20 > > explaining how STUN keepalives would work with SigComp, as well as=20 > > many clarifications from private comments. > >=20 > > There are a few new changes which are listed as potential issues at=20 > > the bottom of this email. I introduced a new status code=20 > instead of=20 > > using 480 or 410, I added a new timer to determine when a flow is=20 > > stable to make sure that the avalanche restart prevention really=20 > > works, and I changed the text about which nodes have to add a Path=20 > > header or store the previous hop flow information. Please=20 > especially=20 > > read through these. If you like these changes please send=20 > me a quick=20 > > email to that effect. If not please send proposed changes. > >=20 > > Until the draft appears in the archives, you can get it here: > >=20 > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si > > p-outbound-05.txt > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-ietf-si > > p-outbound-05.html > >=20 > > thanks, > > -rohan > >=20 > > Changes from outbound-04 to -05: > >=20 > > STUN-related changes: > > Moved STUN Keepalive description to a separate section (section 8). > > Referenced this section from within the relevant sections=20 > in the rest=20 > > of the document. > >=20 > > Added language clarifying that UA MUST NOT send STUN without an=20 > > explicit indication the server supports STUN, and that a UA=20 > MUST stop=20 > > sending STUN if it appears the server does not support it=20 > (ex:initial=20 > > STUN request fails). > >=20 > > Defined a 'sip-stun' option tag. UAs can optionally probe=20 > servers for=20 > > it with OPTIONS. Clarified that UAs SHOULD NOT put this in a=20 > > Proxy-Require. Explain that the first-hop MUST support this=20 > > option-tag. > >=20 > > Clarify that STUN done in conjuction with SIP over TLS is on the=20 > > "inside" of the TLS record-layer. > >=20 > > Added a new section explaining the how STUN keepalives are=20 > used with=20 > > Sigcomp-compressed SIP messages. STUN is "outside" > > the compression layer for UDP, but wrapped inside the=20 > well-known shim=20 > > header for TCP-based transports. > >=20 > > Non-STUN changes: > > Change a MUST to SHOULD based on consensus at last meeting. =20 > > The UAC SHOULD register a flow for each member of the=20 > > outbound-proxy-set. > >=20 > > Added comment about reregistration typically happening over=20 > same flow=20 > > as original registration. > >=20 > > Consistent with my email proposal about Slides 9 and 10=20 > from IETF66, I=20 > > added text about the 'ob' parameter which is used in Path=20 > header field=20 > > URIs to make sure that the previous proxy that added a Path=20 > understood=20 > > outbound processing. The registrar doesn't include=20 > Supported: outbound=20 > > unless it could actually do outbound processing (ex: any=20 > Path headers=20 > > have to have the 'ob' parameter). > >=20 > > Added some text describing what a registration means when=20 > there is an=20 > > instance-id, but no reg-id. This is necessary to make GRUU=20 > work for=20 > > example. > >=20 > > Reworded registrar and proxy in some places (introduce the term=20 > > "Authoritative Proxy"). Several folks pointed out that we=20 > were being=20 > > sloppy with the proxy accepting register requests and the registrar=20 > > forward requests. I think these are all fixed now. > >=20 > > ISSUE: > > Changed 410 Gone to new response code 430 Flow Failed. Based on=20 > > consensus at the last meeting, I was going to change this to 480=20 > > Temporarily Unavailable. Unfortunately this would not work.=20 > A phone=20 > > that uses 480 today for the suggested purpose of saying "Do Not=20 > > Disturb" would trigger the authoritative proxy to delete=20 > all the flows=20 > > of that phone. Oops! I'm hoping this is fine with everyone. > >=20 > > ISSUE: > > Clarified how to decide what a consecutive registration timer is. > > Proposal in the draft is that a flow must be stable for some time=20 > > (default 120 seconds) otherwise previous registration is not=20 > > considered successful. Are folks OK with this? > >=20 > > ISSUE: > > Loosened restrictions on always storing a complete Path=20 > vector back to=20 > > the registrar/authoritative proxy if a previous hop in the=20 > path vector=20 > > is reachable. This was one of the biggest problems with the draft. > > Now it is pretty clear how you can build an archtiecture where the=20 > > registrar is separate from the authoritative proxy, and=20 > also clear how=20 > > you can visit several edge proxies, but not all of them=20 > have to be in=20 > > the Path. Please read this wording carefully in Section 5.1 and=20 > > Section 6. Is this OK? > >=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 Oct 26 06:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2Vr-00050y-1f; Thu, 26 Oct 2006 06:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2Vq-0004xl-0k for sip@ietf.org; Thu, 26 Oct 2006 06:31:02 -0400 Received: from corp2.ipunity.com ([65.106.79.133] helo=exchangevm.ipunity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2Vj-0002Eq-1C for sip@ietf.org; Thu, 26 Oct 2006 06:31:01 -0400 Received: from BLRPC6 ([10.253.253.150]) by exchangevm.ipunity.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Oct 2006 03:30:48 -0700 From: "Darshan Bildikar" To: Date: Thu, 26 Oct 2006 16:00:46 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acb46cv92DamlAaeTgq2ypzjYYJ8WQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 26 Oct 2006 10:30:48.0733 (UTC) FILETIME=[CD9D14D0:01C6F8E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sip] Question on GRUU X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Quote from GRUU draft "However, a UA compliant to this specification SHOULD use a GRUU when populating the Contact header field of dialog-forming and target refresh requests and responses. In other words, a UA compliant to this specification SHOULD use its GRUU as its remote target. This includes the INVITE request, its 2xx response, the SUBSCRIBE [6] request, its 2xx response, the NOTIFY request, and the REFER [7] request, and its 2xx response" If a GRUU is to be used in a target refresh request, then should it not be used in UPDATE too? Isn't UPDATE a target refresh request even though it doesn't create a dialog? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 09:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4ok-0006tu-H0; Thu, 26 Oct 2006 08:58:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd4oi-0006tM-Bx for sip@ietf.org; Thu, 26 Oct 2006 08:58:40 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd4oe-0003W5-Uw for sip@ietf.org; Thu, 26 Oct 2006 08:58:40 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id k9QCwQkd012997; Thu, 26 Oct 2006 07:58:26 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Oct 2006 07:58:25 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Oct 2006 14:58:23 +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] Updated GRUU spec - big changes Date: Thu, 26 Oct 2006 14:58:22 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated GRUU spec - big changes thread-index: Acb4fqybboIeNy9KQICcNReLRrDgwAAfa8IA From: "Drage, Keith \(Keith\)" To: "EKR" , "Rohan Mahy" X-OriginalArrivalTime: 26 Oct 2006 12:58:23.0463 (UTC) FILETIME=[6B71A770:01C6F8FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 to note that full privacy of GRUUs is not dead. We agreed on the list some time back, in association with IETF#66, that the current mechanism of GRUU would not provide this, and in fact in -11 we have put back in more "privacy" than existed in the previous version. What we agreed is a "do this later". Therefore the WG chairs are interested in proposals to build GRUU capabilities with full privacy. It is recognised as something that will take longer, and we may need to define what full privacy is in respect of SIP first. Start writing those internet-drafts to cover this. I am aware we already have one author draft in this area in draft-jbemmel-sip-truu-02 (currently expired). (People are also welcome to come to a different consensus if they wish to!!!!) Regards Keith =20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: 25 October 2006 21:59 > To: Rohan Mahy > Cc: IETF SIP List > Subject: Re: [Sip] Updated GRUU spec - big changes >=20 > "Rohan Mahy" writes: >=20 > > On 10/24/06, EKR wrote: > >> "Rohan Mahy" writes: > >> > On 10/23/06, Jonathan Rosenberg wrote: > >> >> * added "anonymous gruu", known as temporary gruu. A=20 > temporary GRUU is > >> >> assigned when you first register a contact, and an=20 > additional one is > >> >> created on each refresh. All of the ones accumulated over the > >> >> lifetime of the registration remain valid. Each of=20 > them obfuscate > >> >> the AOR and instance ID. Added a description of a stateless > >> >> algorithm for computing these. Lengthy discussion on=20 > the privacy > >> >> implications of using them. > >> > > >> > I just reviewed the extremely lengthy thread on GRUU privacy and=20 > >> > have yet to see anything resembling consensus on which=20 > privacy or=20 > >> > limited-user requirements we are trying to add here. > >> > >> I'm not sure I agree with this assertion, but I certainly=20 > don't think=20 > >> there was consensus on *not* including some privacy mechanisms. > > > > Actually there was such a consensus when we took the=20 > requirements and=20 > > formally handed them to SIP. >=20 > Maybe so, but there's not now, and now is what's important=20 > for assessing WG consensus on moving a document forward. >=20 >=20 > >> > Furthermore I > >> > expect that the mechanism provided could be abused by=20 > UAs that want=20 > >> > a private per call for example, creating a lot of registration=20 > >> > thrash, jeopardizing the avalanche restart prevention=20 > work in outbound. > >> > >> I don't understand what the security problem you're concerned with=20 > >> is. Can you describe the scenario in more detail? > > > > Its not a security problem. It is an operational problem. A user=20 > > agent that fetches new gruu for every new call would add a=20 > substantial=20 > > amount of additional load on a registrar, especially if=20 > that registrar=20 > > was also doing outbound processing. >=20 > I don't see that. Why? >=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=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 Oct 26 09:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Cl-0002Bd-LK; Thu, 26 Oct 2006 09:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Ck-0002B6-Re for sip@ietf.org; Thu, 26 Oct 2006 09:23:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Cg-0000CB-GL for sip@ietf.org; Thu, 26 Oct 2006 09:23:30 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2006 09:23:26 -0400 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 k9QDNQpp003628; Thu, 26 Oct 2006 09:23: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 k9QDNQYJ002167; Thu, 26 Oct 2006 09:23:26 -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, 26 Oct 2006 09:23:26 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 09:23:25 -0400 Message-ID: <4540B6CD.4070702@cisco.com> Date: Thu, 26 Oct 2006 09:23:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Darshan Bildikar Subject: Re: [Sip] Question on GRUU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 13:23:25.0578 (UTC) FILETIME=[EAC636A0:01C6F901] DKIM-Signature: a=rsa-sha1; q=dns; l=1906; t=1161869006; x=1162733006; 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=20on=20GRUU |To:Darshan=20Bildikar=20; X=v=3Dcisco.com=3B=20h=3D3IcSFKsVTEmUCJELeEyR6ZJS+jU=3D; b=J0jMpEV+H1mYgx7GxKQ15cJZDEeVWo/QcUcRrIhDAsaRfTgvOg32SNxcdyqqZLhHwM3FM9J3 uaW/+L6hRyG4ciS6hi11+4NhKcTpS1O/wIhhDTybjOz17PXFGdalLMno; 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: 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 Darshan Bildikar wrote: > Quote from GRUU draft > > "However, a UA compliant to this specification SHOULD use a GRUU when > populating the Contact header field of dialog-forming and target refresh > requests and responses. In other words, a UA compliant to this > specification SHOULD use its GRUU as its remote target. This includes the > INVITE request, its 2xx response, the SUBSCRIBE [6] request, its 2xx > response, the NOTIFY request, and the REFER [7] request, and its 2xx > response" > > If a GRUU is to be used in a target refresh request, then should it not be > used in UPDATE too? Isn't UPDATE a target refresh request even though it > doesn't create a dialog? Once a dialog has been established following the above rules, with a gruu as the contact, it will normally be used in target refresh requests such as reINVITE and UPDATE when there is no intent to refresh the target. Using a target refresh request to change the target has its own issues. I suppose a refresh could remove the gruu as the target and replace it with a non-gruu. If no gruu was used when the dialog was formed, it potentially could be replaced by a gruu as long as all conditions are met with the existing route set - notably the record-routing by the authoritative proxy. (Since the route set cannot be changed, if it doesn't contain the authoritative proxy you are out of luck in this regard.) Changing from one gruu to a different gruu could conceivably work if existing route set covers them both. This would be the case for instance if they were both temporary gruus for the same instance id. (But then there would be little point in doing it.) If they were gruus for different instances with the same AOR, and there is a Path, then it would have to be the identical Path for both. This gets progressively more complex, and makes my head hurt. 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 Oct 26 09:42:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Sv-0001Ki-QK; Thu, 26 Oct 2006 09:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Su-0001Kc-52 for sip@ietf.org; Thu, 26 Oct 2006 09:40:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd5Sr-0003kr-0o for sip@ietf.org; Thu, 26 Oct 2006 09:40:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2006 09:40:09 -0400 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 k9QDe8QR019486; Thu, 26 Oct 2006 09:40:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9QDe0DY010682; Thu, 26 Oct 2006 09:40:04 -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, 26 Oct 2006 09:40:01 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 09:40:00 -0400 Message-ID: <4540BAB0.9060503@cisco.com> Date: Thu, 26 Oct 2006 09:40:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: zhang.lu2@zte.com.cn Subject: Re: [Sip] Help: About Early-Session and Session References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 13:40:00.0749 (UTC) FILETIME=[3BF141D0:01C6F904] DKIM-Signature: a=rsa-sha1; q=dns; l=3909; t=1161870008; x=1162734008; 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]=20Help=3A=20About=20Early-Session=20and=20Session |To:zhang.lu2@zte.com.cn; X=v=3Dcisco.com=3B=20h=3DlrS57brSIjq01Li8rH8Oi/oMZZc=3D; b=sGPYqCQIuGZYWKtNtNo7o1Cn+fHU0qpm6z4x03uGjmrDyYbVFgGRy2qtcwOyqT82mCQenq8g /MhD895DShg9EB5belYwBMiF3WCiCmaCudyFLNwo2+rFjndActPQe6tc; 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: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org, Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org zhang.lu2@zte.com.cn wrote: > > Dear Sip Group, > > There encounters a question when I read RFC 3959 and RFC 3960 which > refer to the Early-Session , that is > > "Does Offer/Answer Model defined in RFC 3264 apply to > Early-Session and Session independently?" There has been little to no discussion of this. All the extensive and detailed investigation of offer/answer, including the offeranswer draft, have avoided this subject. But IMO if the application server model is followed, using the early-session disposition, then indeed the session and early-session must independently follow the offer/answer model. This can potentially lead to some very complex interactions. For instance, the caller could make a offer for the session, and the callee could make an early-session offer in the other direction. Then they both could use preconditions that result in further offers and answers for both session and early-session as those are resolved. Each would presumably be required to follow the rules about only one offer or answer per transaction, but a single transaction might carry an offer or answer for each of session and early-session. I'm not aware of anyone having attempted an implementation of this. If somebody has, please speak up. (Copying Gonzalo since he is author and might know of an implementation, and Robert in case this has ever come up at SIPit.) IMO its extremely unlikely that this will ever be implemented well enough (if at all) to achieve interoperability. There is enough trouble getting basic offer/answer working. Paul > In RFC 3959 section 7, there is a example as below: > A B > | | > |--------(1) INVITE-------->| > | offer | > | | > |<--(2) Session Progress----| > | early-offer | > | answer | > | | > |---------(3) PRACK-------->| > | early-answer | > | | > |<--------(4) 200 OK--------| > | | > | * * | > | ************************* | > |* Early Media *| > | ************************* | > | * * | > | | > |<--------(5) 200 OK--------| > | | > |----------(6) ACK--------->| > | | > > Figure 1: Message flow > > > Hope to have a letter from you soon. > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 26 11:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6hJ-0000Qu-K8; Thu, 26 Oct 2006 10:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6hI-0000Jx-BE for sip@ietf.org; Thu, 26 Oct 2006 10:59:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd6hF-0001O4-4u for sip@ietf.org; Thu, 26 Oct 2006 10:59:08 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 07:59:05 -0700 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 k9QEx4K9015660; Thu, 26 Oct 2006 10:59:04 -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 k9QEx4YJ004219; Thu, 26 Oct 2006 10:59:04 -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, 26 Oct 2006 10:59: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); Thu, 26 Oct 2006 10:59:04 -0400 Message-ID: <4540CD38.4020908@cisco.com> Date: Thu, 26 Oct 2006 10:59:04 -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: Rohan Mahy Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> <86lkn4qfh8.fsf@raman.networkresonance.com> <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> In-Reply-To: <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 14:59:04.0251 (UTC) FILETIME=[474A38B0:01C6F90F] DKIM-Signature: a=rsa-sha1; q=dns; l=4030; t=1161874744; x=1162738744; 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]=20Updated=20GRUU=20spec=20-=20big=20changes |To:Rohan=20Mahy=20; X=v=3Dcisco.com=3B=20h=3D9J1BlY1qWrrKT9rSlWu3ddnh4Nc=3D; b=l6D5QeluQPAuDMmhZRzQHQmOT1AwnBScwAXCTq930eYSTNNinZhvFcscONdwqp0Pl+VhaB+t LUEHJxnHbvAZqirpKcHy/QpnKh95YG8iuqO2IavEZp4ViVVHfM5JXnaB; 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: 34d35111647d654d033d58d318c0d21a 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 inline. Rohan Mahy wrote: > On 10/25/06, Eric Rescorla wrote: > >> "Rohan Mahy" writes: >> >> > On 10/24/06, EKR wrote: >> >> "Rohan Mahy" writes: >> >> > On 10/23/06, Jonathan Rosenberg wrote: >> >> >> * added "anonymous gruu", known as temporary gruu. A temporary >> GRUU is >> >> >> assigned when you first register a contact, and an additional >> one is >> >> >> created on each refresh. All of the ones accumulated over the >> >> >> lifetime of the registration remain valid. Each of them >> obfuscate >> >> >> the AOR and instance ID. Added a description of a stateless >> >> >> algorithm for computing these. Lengthy discussion on the privacy >> >> >> implications of using them. >> >> > >> >> > I just reviewed the extremely lengthy thread on GRUU privacy and >> have >> >> > yet to see anything resembling consensus on which privacy or >> >> > limited-user requirements we are trying to add here. >> >> >> >> I'm not sure I agree with this assertion, but I certainly >> >> don't think there was consensus on *not* including some >> >> privacy mechanisms. >> > >> > Actually there was such a consensus when we took the requirements and >> > formally handed them to SIP. >> >> Maybe so, but there's not now, and now is what's important for >> assessing WG consensus on moving a document forward. > > > I do not see any consensus around privacy requirements. I'm not > saying that one does not exist, or one cannot be forged. However, we > consciously decided to postpone additional privacy work when we > started GRUU. I don't see what has suddenly changed so that we have > to cram a possibly half-assed mechanism into the GRUU spec. There is a difference between adding new privacy features, and releasing a draft which worsens substantially the privacy of the system prior to the specification. GRUU is meant to be a spec that basically always gets used; its a 'core' SIP spec for that reason. So, this was raised as a bug and I think it can legitimately be qualified as such. > >> >> > Furthermore I >> >> > expect that the mechanism provided could be abused by UAs that >> want a >> >> > private per call for example, creating a lot of registration thrash, >> >> > jeopardizing the avalanche restart prevention work in outbound. >> >> >> >> I don't understand what the security problem you're concerned with >> >> is. Can you describe the scenario in more detail? >> > >> > Its not a security problem. It is an operational problem. A user >> > agent that fetches new gruu for every new call would add a substantial >> > amount of additional load on a registrar, especially if that registrar >> > was also doing outbound processing. >> >> I don't see that. Why? > > > A registrar sized to handle x UAs with an average of just over 2 > registrations per hour suddenly finds a non-trivial number of its UAs > registering 10, 20, or 50 times during the busiest period. Indeed if a UA did this, it would be a problem. This is why the mechanism was purposefully designed so that users would get new temporary gruu as part of their 'normal' refresh. There is virtually no reason why a UA would perform extra registrations. Its only if a UA wants to invalidate a temporary GRUU ahead of its removal. However, we already have standards based mechanisms for achieving that goal (via consent framework) that are far less onerous. The GRUU spec also recommends against these extra registrations for the same reasons you are raising. -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 Thu Oct 26 11:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd71Z-0005uC-VA; Thu, 26 Oct 2006 11:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd71X-0005n0-Qh for sip@ietf.org; Thu, 26 Oct 2006 11:20:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd71U-0006h6-Du for sip@ietf.org; Thu, 26 Oct 2006 11:20:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2006 11:20:00 -0400 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 k9QFK0AW026739; Thu, 26 Oct 2006 11:20: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 k9QFK0DM013717; Thu, 26 Oct 2006 11:20:00 -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); Thu, 26 Oct 2006 11:20:00 -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); Thu, 26 Oct 2006 11:19:59 -0400 Message-ID: <4540D21F.5000102@cisco.com> Date: Thu, 26 Oct 2006 11:19:59 -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: Rohan Mahy Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> In-Reply-To: <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 15:19:59.0454 (UTC) FILETIME=[3372FFE0:01C6F912] DKIM-Signature: a=rsa-sha1; q=dns; l=4235; t=1161876000; x=1162740000; 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]=20Updated=20GRUU=20spec=20-=20big=20changes |To:Rohan=20Mahy=20; X=v=3Dcisco.com=3B=20h=3D9J1BlY1qWrrKT9rSlWu3ddnh4Nc=3D; b=uAovrZYmRzo24u9DQ+a1rd+IiomuBmpqCJ2enXG53z2v8a9biWbQt3F8obYYwrlEC75RuBXp 4hLqdKkePbIj8xWLeXp1PTBsGAcgjfXRFBSTNBVV1bUaWdpbDzXa8a6t; 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 inline. Rohan Mahy wrote: > I think these changes definitely improved readability. > >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is >> assigned when you first register a contact, and an additional one is >> created on each refresh. All of the ones accumulated over the >> lifetime of the registration remain valid. Each of them obfuscate >> the AOR and instance ID. Added a description of a stateless >> algorithm for computing these. Lengthy discussion on the privacy >> implications of using them. > > > I just reviewed the extremely lengthy thread on GRUU privacy and have > yet to see anything resembling consensus on which privacy or > limited-user requirements we are trying to add here. Well we had consensus I think on trying to do as good as rfc3261 alone. There was some debate on whether this would in fact require you to change Contact URI on a call by call basis (since you could do that with rfc3261). But there was consensus on that requirement I thought. Furthermore I > expect that the mechanism provided could be abused by UAs that want a > private per call for example, creating a lot of registration thrash, > jeopardizing the avalanche restart prevention work in outbound. Per my other note, getting a different gruu per call does not require extra registrations. A UA with an objective of being malicious, and placing load on the server, can re-register a lot with or without the gruu spec. > >> * removed completely the grid concept and associated processing. The >> plan is to instead use loose routing or an alternative like it which >> would allow a UA to add params to an AOR or a GRUU and get them back >> in a request it receives. > > > We had a requirement in the GRUU draft to be able to manufacture a > whole family of GRUU. Grid satisfied this requirement. I STRONGLY > object to any attempt to make this functionality depend on an untried, > substantially risky new mechanism. I will take this to a process > appeal if necessary. During his review, ekr raised the issue that this was really a general issue and that the proposed solution was highly specific to gruu, and that a better, more general purpose solution was reqiured (one that allowed you to manufacture identities against your AOR too). This was a good point and there was consensus to do a more general solution. Thus, the functionality was pulled from GRUU, and I submitted an individual I-D proposing a solution. You are welcome to submit a draft with your solution. Are you objecting to the proposed mechanism, or objecting to making it more general purpose and in a separate spec? >> * removed bit about registering different contacts to each AOR when a >> UA has multiple AOR; will leave that to the UA loose route spec > > > Again, I object to making this document depend on the UA loose routing > spec. If you want to tone down the language, I propose something like > this: > > "Note a User Agent with multiple AORs needs to insure that it can > distinguish requests to each AOR. One way to insure this property is > to use a unique Contact URI per AOR." The GRUU spec more or less talks about doing this, but not in a normative fashion as it did in -10. The following text appears in -11: When a UA receives a request, the GRUU placed into the Contact header field of a 2xx response SHOULD be the one associated with the AOR or GRUU to which the request was most recently targeted. There are several ways to determine the AOR or GRUU to which a request was sent. For example, if a UA registered a different contact to each AOR (by using a different user part of the URI), the Request-URI (which contains that contact) will indicate the AOR. are you objecting to this? -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 Thu Oct 26 11:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd76S-0001op-SB; Thu, 26 Oct 2006 11:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd76R-0001ny-H0 for sip@ietf.org; Thu, 26 Oct 2006 11:25:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd76O-0007yi-9Z for sip@ietf.org; Thu, 26 Oct 2006 11:25:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 08:25:04 -0700 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 k9QFP4TO029893; Thu, 26 Oct 2006 11:25:04 -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 k9QFP3YL014658; Thu, 26 Oct 2006 11:25:03 -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); Thu, 26 Oct 2006 11:25:03 -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); Thu, 26 Oct 2006 11:25:03 -0400 Message-ID: <4540D34F.1000701@cisco.com> Date: Thu, 26 Oct 2006 11:25:03 -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: Paul Kyzivat Subject: Re: [Sip] Question on GRUU References: <4540B6CD.4070702@cisco.com> In-Reply-To: <4540B6CD.4070702@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 15:25:03.0399 (UTC) FILETIME=[E89D5370:01C6F912] DKIM-Signature: a=rsa-sha1; q=dns; l=2775; t=1161876304; x=1162740304; 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=20on=20GRUU |To:Paul=20Kyzivat=20; X=v=3Dcisco.com=3B=20h=3DUfSvqrHsFv/IJIdosSOcK/nPxFs=3D; b=hhuVvXP4F+SR9HDWEIwMXu9pJ9qdn7W7IozlVgzlHPuHTfrBISq+hRiMsoiylTaC1ivVPXAB U0ieSyTfm77vXY1jengrK3AMZ/tGq2uv67pmzpH2F0HEMNw1E/PikKXt; 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: 52f7a77164458f8c7b36b66787c853da 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 All of that said, I think the answer is 'yes' and that UPDATE needs to be added to the list. -Jonathan R. Paul Kyzivat wrote: > > > Darshan Bildikar wrote: > >> Quote from GRUU draft >> >> "However, a UA compliant to this specification SHOULD use a GRUU when >> populating the Contact header field of dialog-forming and target refresh >> requests and responses. In other words, a UA compliant to this >> specification SHOULD use its GRUU as its remote target. This includes >> the >> INVITE request, its 2xx response, the SUBSCRIBE [6] request, its 2xx >> response, the NOTIFY request, and the REFER [7] request, and its 2xx >> response" >> >> If a GRUU is to be used in a target refresh request, then should it >> not be >> used in UPDATE too? Isn't UPDATE a target refresh request even though it >> doesn't create a dialog? > > > Once a dialog has been established following the above rules, with a > gruu as the contact, it will normally be used in target refresh requests > such as reINVITE and UPDATE when there is no intent to refresh the target. > > Using a target refresh request to change the target has its own issues. > I suppose a refresh could remove the gruu as the target and replace it > with a non-gruu. If no gruu was used when the dialog was formed, it > potentially could be replaced by a gruu as long as all conditions are > met with the existing route set - notably the record-routing by the > authoritative proxy. (Since the route set cannot be changed, if it > doesn't contain the authoritative proxy you are out of luck in this > regard.) > > Changing from one gruu to a different gruu could conceivably work if > existing route set covers them both. This would be the case for instance > if they were both temporary gruus for the same instance id. (But then > there would be little point in doing it.) If they were gruus for > different instances with the same AOR, and there is a Path, then it > would have to be the identical Path for both. This gets progressively > more complex, and makes my head hurt. > > 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 > -- 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 Oct 26 11:29:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd792-0004jm-5M; Thu, 26 Oct 2006 11:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd790-0004c5-ME for sip@ietf.org; Thu, 26 Oct 2006 11:27:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd78y-0000EO-AN for sip@ietf.org; Thu, 26 Oct 2006 11:27:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 08:27:44 -0700 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 k9QFRiov031389; Thu, 26 Oct 2006 11:27:44 -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 k9QFRcYR015690; Thu, 26 Oct 2006 11:27:43 -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, 26 Oct 2006 11:27:42 -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, 26 Oct 2006 11:27:41 -0400 Message-ID: <4540D3ED.2010701@cisco.com> Date: Thu, 26 Oct 2006 11:27:41 -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: Jonathan Rosenberg Subject: Re: [Sip] Question on GRUU References: <4540B6CD.4070702@cisco.com> <4540D34F.1000701@cisco.com> In-Reply-To: <4540D34F.1000701@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 15:27:41.0831 (UTC) FILETIME=[470C2170:01C6F913] DKIM-Signature: a=rsa-sha1; q=dns; l=2958; t=1161876464; x=1162740464; 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=20on=20GRUU |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DUfSvqrHsFv/IJIdosSOcK/nPxFs=3D; b=uMgqRL0RLvIFPYavoKfra0oFGFMnap7k9QsWKcK3hTg7f9P2LblcpxftX8Rgfi/h9QLmZFFq t6sRUDQgyUc8Zwvfsa46OhhJtEzL8XgmUHum48owLwCrObCBt/P9E288; 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: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, 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 Actually, its in -11 already. The text you are quoting is from -10. -Jonathan R. Jonathan Rosenberg wrote: > All of that said, I think the answer is 'yes' and that UPDATE needs to > be added to the list. > > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Darshan Bildikar wrote: >> >>> Quote from GRUU draft >>> >>> "However, a UA compliant to this specification SHOULD use a GRUU when >>> populating the Contact header field of dialog-forming and target refresh >>> requests and responses. In other words, a UA compliant to this >>> specification SHOULD use its GRUU as its remote target. This >>> includes the >>> INVITE request, its 2xx response, the SUBSCRIBE [6] request, its 2xx >>> response, the NOTIFY request, and the REFER [7] request, and its 2xx >>> response" >>> >>> If a GRUU is to be used in a target refresh request, then should it >>> not be >>> used in UPDATE too? Isn't UPDATE a target refresh request even though it >>> doesn't create a dialog? >> >> >> >> Once a dialog has been established following the above rules, with a >> gruu as the contact, it will normally be used in target refresh >> requests such as reINVITE and UPDATE when there is no intent to >> refresh the target. >> >> Using a target refresh request to change the target has its own >> issues. I suppose a refresh could remove the gruu as the target and >> replace it with a non-gruu. If no gruu was used when the dialog was >> formed, it potentially could be replaced by a gruu as long as all >> conditions are met with the existing route set - notably the >> record-routing by the authoritative proxy. (Since the route set cannot >> be changed, if it doesn't contain the authoritative proxy you are out >> of luck in this regard.) >> >> Changing from one gruu to a different gruu could conceivably work if >> existing route set covers them both. This would be the case for >> instance if they were both temporary gruus for the same instance id. >> (But then there would be little point in doing it.) If they were gruus >> for different instances with the same AOR, and there is a Path, then >> it would have to be the identical Path for both. This gets >> progressively more complex, and makes my head hurt. >> >> 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 >> > -- 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 Oct 26 11:46:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7Ot-00050b-DM; Thu, 26 Oct 2006 11:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7Or-0004tU-Fe for sip@ietf.org; Thu, 26 Oct 2006 11:44:09 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd7On-0003pg-37 for sip@ietf.org; Thu, 26 Oct 2006 11:44:09 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 54EA6AC423; Thu, 26 Oct 2006 18:44:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17728.55235.282331.526853@harjus.tutpro.com> Date: Thu, 26 Oct 2006 18:44:03 +0300 To: Jonathan Rosenberg Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <4540D21F.5000102@cisco.com> References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <4540D21F.5000102@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Jonathan Rosenberg writes: > Well we had consensus I think on trying to do as good as rfc3261 alone. > There was some debate on whether this would in fact require you to > change Contact URI on a call by call basis (since you could do that with > rfc3261). But there was consensus on that requirement I thought. yes, but i didn't get a clear answer to the issue regarding the host part in the pseudo anonymous gruu. does it need to reveal the actual domain of the caller? in rfc3261, only ip address is revealed. -- 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 Oct 26 11:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7TW-0001GC-Ow; Thu, 26 Oct 2006 11:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd7TV-0001Dc-Fc for sip@ietf.org; Thu, 26 Oct 2006 11:48:57 -0400 Received: from jes-fe1.zx.nl ([194.187.76.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd7TN-0004SZ-5n for sip@ietf.org; Thu, 26 Oct 2006 11:48:57 -0400 Received: from Inbox ([84.241.198.224]) by jes-fe1.zx.nl (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0J7R005ZE52WEA60@jes-fe1.zx.nl> for sip@ietf.org; Thu, 26 Oct 2006 17:42:44 +0100 (WEST) Date: Thu, 26 Oct 2006 17:48:36 +0200 From: Jeroen Van Bemmel Subject: RE: [Sip] Updated GRUU spec - big changes To: "Drage, Keith (Keith)" , EKR , Rohan Mahy Message-id: <0J7R005ZF52YEA60@jes-fe1.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: 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 am aware we already have one author >draft in this area in draft-jbemmel-sip-truu-02 (currently expired). For the record: it will expire on 13th of november. I have a minor update r= eady, but am waiting to see which direction GRUU goes. It may be that the d= elta becomes so small that I can drop mine Regards, Jeroen > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: 25 October 2006 21:59 > To: Rohan Mahy > Cc: IETF SIP List _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 12:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8J2-0004Fn-RZ; Thu, 26 Oct 2006 12:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8J0-0003rN-L6 for sip@ietf.org; Thu, 26 Oct 2006 12:42:10 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Ix-0004jg-7E for sip@ietf.org; Thu, 26 Oct 2006 12:42:10 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id k9QGg6fP027973; Thu, 26 Oct 2006 11:42:06 -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, 26 Oct 2006 11:42:06 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Oct 2006 18:42:04 +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] Updated GRUU spec - big changes Date: Thu, 26 Oct 2006 18:42:03 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918069AF56@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated GRUU spec - big changes thread-index: Acb5FjN1aEtKcRmaR5KJ0q0Ny7n2SAAB2vSg From: "Drage, Keith \(Keith\)" To: "Jeroen Van Bemmel" , "EKR" , "Rohan Mahy" X-OriginalArrivalTime: 26 Oct 2006 16:42:04.0243 (UTC) FILETIME=[AADA2A30:01C6F91D] 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 TRUU. If you put garbage into the draft tracker, you get garbage out. It is still current. regards Keith =20 > -----Original Message----- > From: Jeroen Van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: 26 October 2006 16:49 > To: Drage, Keith (Keith); EKR; Rohan Mahy > Cc: IETF SIP List > Subject: RE: [Sip] Updated GRUU spec - big changes >=20 >=20 > >I am aware we already have one author > >draft in this area in draft-jbemmel-sip-truu-02 (currently expired). >=20 > For the record: it will expire on 13th of november. I have a=20 > minor update ready, but am waiting to see which direction=20 > GRUU goes. It may be that the delta becomes so small that I=20 > can drop mine >=20 > Regards, > Jeroen >=20 > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: 25 October 2006 21:59 > > To: Rohan Mahy > > Cc: IETF SIP List >=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 Oct 26 12:51:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Q9-0007im-BB; Thu, 26 Oct 2006 12:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd8Q7-0007iU-ER for sip@ietf.org; Thu, 26 Oct 2006 12:49:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd8Q5-0006C3-2g for sip@ietf.org; Thu, 26 Oct 2006 12:49:31 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 26 Oct 2006 09:49:29 -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 k9QGnSM2005515; Thu, 26 Oct 2006 09:49:28 -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 k9QGmvP3029714; Thu, 26 Oct 2006 09:49:23 -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); Thu, 26 Oct 2006 12:49:18 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Oct 2006 12:49:18 -0400 Message-ID: <4540E70E.20605@cisco.com> Date: Thu, 26 Oct 2006 12:49:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <4540D21F.5000102@cisco.com> <17728.55235.282331.526853@harjus.tutpro.com> In-Reply-To: <17728.55235.282331.526853@harjus.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 16:49:18.0651 (UTC) FILETIME=[ADC790B0:01C6F91E] DKIM-Signature: a=rsa-sha1; q=dns; l=847; t=1161881368; x=1162745368; 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]=20Updated=20GRUU=20spec=20-=20big=20changes; X=v=3Dcisco.com=3B=20h=3DPbHfj1WDANfz+aDcemlfuaP+k/c=3D; b=XAhsr0EIyKFWFs3PogIM74VdcrEDRGvMqwRFGiVon/IUqsM0t9pwj7py/9qK6VY/C719HQpR vnytLNxF7SYO1PYIWw8Ba4CE3GwpRXsS2Qj82rvuHJhoVfb1PkcjxrRC; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Juha Heinanen wrote: > Jonathan Rosenberg writes: > > > Well we had consensus I think on trying to do as good as rfc3261 alone. > > There was some debate on whether this would in fact require you to > > change Contact URI on a call by call basis (since you could do that with > > rfc3261). But there was consensus on that requirement I thought. > > yes, but i didn't get a clear answer to the issue regarding the host > part in the pseudo anonymous gruu. does it need to reveal the actual > domain of the caller? in rfc3261, only ip address is revealed. It doesn't need to reveal the actual domain of the caller *directly*. But it does need to route back to the authoritative proxy for the AOR. If the registrar has a way to obscure the domain and still preserve the proper routing it is free to do so. 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 Oct 26 14:13:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9fw-0005VS-LV; Thu, 26 Oct 2006 14:09:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd9fu-0005Ut-Se for sip@ietf.org; Thu, 26 Oct 2006 14:09:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd9ev-0001V5-MQ for sip@ietf.org; Thu, 26 Oct 2006 14:08:56 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 11:08:53 -0700 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 k9QI8rYH005300; Thu, 26 Oct 2006 14:08: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 k9QI8qDO007577; Thu, 26 Oct 2006 14:08:53 -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, 26 Oct 2006 14:08:52 -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); Thu, 26 Oct 2006 14:08:52 -0400 Message-ID: <4540F9B4.304@cisco.com> Date: Thu, 26 Oct 2006 14:08:52 -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: Paul Kyzivat Subject: Re: [Sip] Updated GRUU spec - big changes References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <4540D21F.5000102@cisco.com> <17728.55235.282331.526853@harjus.tutpro.com> <4540E70E.20605@cisco.com> In-Reply-To: <4540E70E.20605@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 18:08:52.0626 (UTC) FILETIME=[CB4A5720:01C6F929] DKIM-Signature: a=rsa-sha1; q=dns; l=1690; t=1161886133; x=1162750133; 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]=20Updated=20GRUU=20spec=20-=20big=20changes |To:Paul=20Kyzivat=20; X=v=3Dcisco.com=3B=20h=3D9J1BlY1qWrrKT9rSlWu3ddnh4Nc=3D; b=W6yitj25L7YGdM3hnvjEhKULy+dwlkRrrYxlAZjxoKZgL5/fngBSLLXxm9kltvOZb0Ei1eeU kiBtscdY5oHyHS158aY+Z7C4s0UmtsMIRnNysyIye2KtkeEcPq4T3PCE; 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: IETF SIP List , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Right. Note that the domain part of the GRUU could be an IP address too; though this has issues. And while it is true that, prior to GRUU, the Contact doesn't even have to route back to the provider (it can be sip:anonymous@anonymous.invalid), the Via header inserted by the last proxy in the SP network DOES have to route back to that provider. So, RFC 3261 is already telling someone the identity of my SIP provider. -Jonathan R. Paul Kyzivat wrote: > > > Juha Heinanen wrote: > >> Jonathan Rosenberg writes: >> >> > Well we had consensus I think on trying to do as good as rfc3261 >> alone. > There was some debate on whether this would in fact require >> you to > change Contact URI on a call by call basis (since you could >> do that with > rfc3261). But there was consensus on that requirement >> I thought. >> >> yes, but i didn't get a clear answer to the issue regarding the host >> part in the pseudo anonymous gruu. does it need to reveal the actual >> domain of the caller? in rfc3261, only ip address is revealed. > > > It doesn't need to reveal the actual domain of the caller *directly*. > But it does need to route back to the authoritative proxy for the AOR. > If the registrar has a way to obscure the domain and still preserve the > proper routing it is free to do so. > > Paul > -- 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 Oct 26 14:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAHj-0006Vl-A2; Thu, 26 Oct 2006 14:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAHg-0006Tm-3J for sip@ietf.org; Thu, 26 Oct 2006 14:48:56 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdAGe-00086v-7H for sip@ietf.org; Thu, 26 Oct 2006 14:47:54 -0400 Received: from [64.101.181.168] (dhcp-64-101-181-168.cisco.com [64.101.181.168]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9QHp67T024190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 12:51:07 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DB775C8@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DB775C8@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05F32587-3EAE-44AB-9D06-1D0A31273739@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 26 Oct 2006 13:47:33 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes Subject: [Sip] Re: TLS meaning X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 25, 2006, at 2:08 PM, Francois Audet wrote: > So, to summarize, you are NOT happy with the current consensus, and > you > are proposing something completely different, i.e., that instead of > just > the current cludgy "last-hop exception rule", we also add a new > "first-hop > exception" (and I would imagine a new "any hop exception" rule)? > Good summary. > Unlike the current "last hop exception rule" which imposes absolutely > no security requirements, your "any hop exception rule" would change > this > it to a "decent security equivalent to TLS" rule. > Yep. > This would entail finding all the instances of "TLS" in RFC 3261 and > make the > according changes. > That's one way to approach it. Another way to do it would be another RFC that extends 3261 and says basically "Wherever RFC 321 says TLS, please substitute . . . " > This is a gigantic change from RFC 2961. I don't think it is > reasonable. > Doesn't have to be reasonable if it's necessary. > It is orders of magnitude bigger than what is discussed in > draft-audet-sip-sips-guidelines which does NOT attempt to redefine > the meaning of sips, and does NOT invalidate RFC 3261. > Not saying your draft isn't needed. Just saying it isn't enough to really fix the problem. > My take is that using other protocols than TLS is perfectly fine. > However, > it does not mean that we should be using sips in that case. I'd argue > that > using sip is perfectly fine in those cases. > > If a network for example relies on IPsec, maybe there is no need to > use > sips at all. > So how would you propose that a user say "I expect you to ship this request and an responses to it over secured links, and if you can't, I want you to reject it" without using sips:? > I think we need to be pragmatic here. We can not invalidate huge > chunks > of > RFC 3261 in the way you are proposing. I believe otherwise. -- 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 Oct 26 14:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAI5-0006hF-V3; Thu, 26 Oct 2006 14:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAI4-0006gO-Vb for sip@ietf.org; Thu, 26 Oct 2006 14:49:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdACS-0007XY-P4 for sip@ietf.org; Thu, 26 Oct 2006 14:43:34 -0400 Received: by ug-out-1314.google.com with SMTP id 72so390782ugd for ; Thu, 26 Oct 2006 11:43:31 -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=Ez3+ibmGSoohYafaBGs/sdMAfvAqGgngTNagMCdGaVnlXT3CnEqIUDc0LWwUto4fTrDBV/GavdUIqy11au2VxqYwW7jSydgjooiNfxJx/OPHDddhlOJ4UFMiEef7u+A/2G0JnHO0XQDyxno5RjIEdhlzDArpo3VIqhPL80n6Jkc= Received: by 10.78.204.20 with SMTP id b20mr3023684hug; Thu, 26 Oct 2006 11:43:30 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Thu, 26 Oct 2006 11:43:30 -0700 (PDT) Message-ID: <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> Date: Thu, 26 Oct 2006 11:43:30 -0700 From: "Rohan Mahy" To: "Drage, Keith (Keith)" Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Keith, To that end, I am reposting here some ideas I sent to the GRUU design team for an explicit lifetime and explicit privacy mechanism. Note that I am using gruu-10 style syntax because I was more familiar with that syntax when I wrote this up: ----------- I'd been meaning to post some of my thoughts about a more explicit method of fetching limited-use, pseudonymous, and/or anonymous GRUUs. I had been hoping to submit a draft on this topic for several IETFs now, but did not have the cycles. (Last time I spent my extra -00 draft energy on the speermint fiasco.) I heard several different sets of requirements mentioned on the call yesterday. I think this concept addresses all the requirements I think I heard, including my one-GRUU-per-call scenario, and some assumed requirements to do spam prevention from ekr. I think this mechanism has some additional nice properties. It works like this. First the user registers and gets his/her public GRUU as in gruu-10. REGISTER sip:example.com To: From: Contact: ;+sip.instance="" SIP/2.0 200 OK To: From: Contact: ;+sip.instance="" ;expires=3600;gruu="sip:rohan@example.com;opaque=12345;gruu" In addition, anytime the user wants a new limited-use or anonymous GRUU, he/she sends a new register request like this: REGISTER sip:example.com To: From: Contact: Expires: 86400 Privacy: gruu SIP/2.0 200 OK To: From: Contact: ;expires=86400 ;gruu="sip:8nWq%lGtm+ar2@example.com;gruu" Contact: ;expires=42104 ;gruu="sip:kajsd92aa2jWD@example.com;gruu" Contact: ;expires=432710 ;gruu="sip:rohan@example.com;opaque=lkas82;gruu" The limited-use GRUU can have a much longer lifetime than an ordinary registration. Also, since they are tied to a public GRUU instead of to an ordinary Contact URI, the binding can survive reboots, power offs of several hours, etc. A UA can refresh or explicitly destroy these GRUU if it desires. It can have several active limited-use GRUU at a time, each of which can have different properties (for example different priv-values). [The example above has one new anonymous GRUU that lasts a day, another day-by-day anonymous GRUU that is half expired, and a non-anonymous limited use GRUU (for a sales person) that was valid for a week and still has 5 days left.] The UA can remember its limited-use GRUU in non-volatile storage or it can issue a simple REGISTER query to get a list of all active limited-use GRUUs. If the UA has been off for an extended period of time and needs a limited-use GRUU, it needs to issue two registrations, BUT it does not need 2 RTTs. It can issue both REGISTER requests at effectively the same time (in any order). I hope this makes sense. thanks, -rohan On 10/26/06, Drage, Keith (Keith) wrote: > Just to note that full privacy of GRUUs is not dead. > > We agreed on the list some time back, in association with IETF#66, that > the current mechanism of GRUU would not provide this, and in fact in -11 > we have put back in more "privacy" than existed in the previous version. > > What we agreed is a "do this later". Therefore the WG chairs are > interested in proposals to build GRUU capabilities with full privacy. It > is recognised as something that will take longer, and we may need to > define what full privacy is in respect of SIP first. Start writing those > internet-drafts to cover this. I am aware we already have one author > draft in this area in draft-jbemmel-sip-truu-02 (currently expired). > > (People are also welcome to come to a different consensus if they wish > to!!!!) > > Regards > > Keith > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: 25 October 2006 21:59 > > To: Rohan Mahy > > Cc: IETF SIP List > > Subject: Re: [Sip] Updated GRUU spec - big changes > > > > "Rohan Mahy" writes: > > > > > On 10/24/06, EKR wrote: > > >> "Rohan Mahy" writes: > > >> > On 10/23/06, Jonathan Rosenberg wrote: > > >> >> * added "anonymous gruu", known as temporary gruu. A > > temporary GRUU is > > >> >> assigned when you first register a contact, and an > > additional one is > > >> >> created on each refresh. All of the ones accumulated over the > > >> >> lifetime of the registration remain valid. Each of > > them obfuscate > > >> >> the AOR and instance ID. Added a description of a stateless > > >> >> algorithm for computing these. Lengthy discussion on > > the privacy > > >> >> implications of using them. > > >> > > > >> > I just reviewed the extremely lengthy thread on GRUU privacy and > > >> > have yet to see anything resembling consensus on which > > privacy or > > >> > limited-user requirements we are trying to add here. > > >> > > >> I'm not sure I agree with this assertion, but I certainly > > don't think > > >> there was consensus on *not* including some privacy mechanisms. > > > > > > Actually there was such a consensus when we took the > > requirements and > > > formally handed them to SIP. > > > > Maybe so, but there's not now, and now is what's important > > for assessing WG consensus on moving a document forward. > > > > > > >> > Furthermore I > > >> > expect that the mechanism provided could be abused by > > UAs that want > > >> > a private per call for example, creating a lot of registration > > >> > thrash, jeopardizing the avalanche restart prevention > > work in outbound. > > >> > > >> I don't understand what the security problem you're concerned with > > >> is. Can you describe the scenario in more detail? > > > > > > Its not a security problem. It is an operational problem. A user > > > agent that fetches new gruu for every new call would add a > > substantial > > > amount of additional load on a registrar, especially if > > that registrar > > > was also doing outbound processing. > > > > I don't see that. Why? > > > > -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 Thu Oct 26 14:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAJz-0008Cv-U8; Thu, 26 Oct 2006 14:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAJz-0008Cj-6B for sip@ietf.org; Thu, 26 Oct 2006 14:51:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdAJw-0000m3-I8 for sip@ietf.org; Thu, 26 Oct 2006 14:51:19 -0400 Received: by ug-out-1314.google.com with SMTP id 72so392658ugd for ; Thu, 26 Oct 2006 11:51:15 -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=JVcsVMuDcou8/SO/pzmV6i70U6MHuHkJHudk4so4mlEDqwFSbpLZKrdpPICZr3Ln4pQBzDvN8nz/LCS8jwbJMENCVkOQt0KwzIKjTMUjNU1W70g+PHivHapE+6AOFsE7ounlIsmUP0WjOCZYlh0hC+d0Zqtuyt8k41pc1gxPfT4= Received: by 10.78.203.13 with SMTP id a13mr2398810hug; Thu, 26 Oct 2006 11:51:13 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Thu, 26 Oct 2006 11:51:13 -0700 (PDT) Message-ID: <953beacc0610261151he3be5deo13846a8d1451e6e9@mail.gmail.com> Date: Thu, 26 Oct 2006 11:51:13 -0700 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <4540CD38.4020908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <86u01tdzxf.fsf@delta.rtfm.com> <953beacc0610251300n72bcfd36p2f1e867517082a91@mail.gmail.com> <86lkn4qfh8.fsf@raman.networkresonance.com> <953beacc0610251705t4d3037f8p524a430ac43de2f5@mail.gmail.com> <4540CD38.4020908@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 Jonathan, In practice, I don't think GRUU "substantially worsens" the privacy of SIP as it is deployed and will be deployed. This does not worsen privacy for UAs who are talking to PSTN gateways or UAs that are already going through B2BUAs that insert media relays. In any case the security properties of GRUU were not considered a "bug" two years ago. I strongly suspect that folks that want any real privacy will want at least "service-provider level" IP address anonymity. The fact that we do not even have a consistent vocabularly in this group to talk about these privacy issues strongly hints that we need an explicit requirements discussion, and an explicit mechanism, to enable GRUU privacy. thanks, -rohan On 10/26/06, Jonathan Rosenberg wrote: > inline. > > Rohan Mahy wrote: > > > On 10/25/06, Eric Rescorla wrote: > > > >> "Rohan Mahy" writes: > >> > >> > On 10/24/06, EKR wrote: > >> >> "Rohan Mahy" writes: > >> >> > On 10/23/06, Jonathan Rosenberg wrote: > >> >> >> * added "anonymous gruu", known as temporary gruu. A temporary > >> GRUU is > >> >> >> assigned when you first register a contact, and an additional > >> one is > >> >> >> created on each refresh. All of the ones accumulated over the > >> >> >> lifetime of the registration remain valid. Each of them > >> obfuscate > >> >> >> the AOR and instance ID. Added a description of a stateless > >> >> >> algorithm for computing these. Lengthy discussion on the privacy > >> >> >> implications of using them. > >> >> > > >> >> > I just reviewed the extremely lengthy thread on GRUU privacy and > >> have > >> >> > yet to see anything resembling consensus on which privacy or > >> >> > limited-user requirements we are trying to add here. > >> >> > >> >> I'm not sure I agree with this assertion, but I certainly > >> >> don't think there was consensus on *not* including some > >> >> privacy mechanisms. > >> > > >> > Actually there was such a consensus when we took the requirements and > >> > formally handed them to SIP. > >> > >> Maybe so, but there's not now, and now is what's important for > >> assessing WG consensus on moving a document forward. > > > > > > I do not see any consensus around privacy requirements. I'm not > > saying that one does not exist, or one cannot be forged. However, we > > consciously decided to postpone additional privacy work when we > > started GRUU. I don't see what has suddenly changed so that we have > > to cram a possibly half-assed mechanism into the GRUU spec. > > There is a difference between adding new privacy features, and releasing > a draft which worsens substantially the privacy of the system prior to > the specification. GRUU is meant to be a spec that basically always gets > used; its a 'core' SIP spec for that reason. > > So, this was raised as a bug and I think it can legitimately be > qualified as such. > > > > >> >> > Furthermore I > >> >> > expect that the mechanism provided could be abused by UAs that > >> want a > >> >> > private per call for example, creating a lot of registration thrash, > >> >> > jeopardizing the avalanche restart prevention work in outbound. > >> >> > >> >> I don't understand what the security problem you're concerned with > >> >> is. Can you describe the scenario in more detail? > >> > > >> > Its not a security problem. It is an operational problem. A user > >> > agent that fetches new gruu for every new call would add a substantial > >> > amount of additional load on a registrar, especially if that registrar > >> > was also doing outbound processing. > >> > >> I don't see that. Why? > > > > > > A registrar sized to handle x UAs with an average of just over 2 > > registrations per hour suddenly finds a non-trivial number of its UAs > > registering 10, 20, or 50 times during the busiest period. > > Indeed if a UA did this, it would be a problem. > > This is why the mechanism was purposefully designed so that users would > get new temporary gruu as part of their 'normal' refresh. There is > virtually no reason why a UA would perform extra registrations. Its only > if a UA wants to invalidate a temporary GRUU ahead of its removal. > However, we already have standards based mechanisms for achieving that > goal (via consent framework) that are far less onerous. > > The GRUU spec also recommends against these extra registrations for the > same reasons you are raising. > > -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 Thu Oct 26 14:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAKY-0000mV-IC; Thu, 26 Oct 2006 14:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAIM-0006uq-AR for sip@ietf.org; Thu, 26 Oct 2006 14:49:38 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdA6R-0006si-ET for sip@ietf.org; Thu, 26 Oct 2006 14:37:22 -0400 Received: by ug-out-1314.google.com with SMTP id 72so389285ugd for ; Thu, 26 Oct 2006 11:37:18 -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=COAkOvRGr2cv+Nx3Kvbh2x9VTzWhZ6PkYAirr3y5CGjWlsaIOvXY+JlP7DC5IErfO1+ehSlVzkAdcGB0v6Qa3WUiU9qR2o2G6YyLZCPumP/nZfrjwqzRFJ71hWa+reB9+uhCLyrNfyxVcUe5FPMqtzSdYqZU2JuW66plaI2Ydko= Received: by 10.78.90.10 with SMTP id n10mr2376273hub; Thu, 26 Oct 2006 11:37:17 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Thu, 26 Oct 2006 11:37:17 -0700 (PDT) Message-ID: <953beacc0610261137q4605412aja44bfa93f718ecc@mail.gmail.com> Date: Thu, 26 Oct 2006 11:37:17 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <86y7r3q49n.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> <86fydcqfdx.fsf@raman.networkresonance.com> <953beacc0610251707j5777516bsa6551ca494d5f91b@mail.gmail.com> <86y7r3q49n.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Ekr, As I said in an earlier mail (perhaps not as clearly as necessary), if you want to propose a general grid-like mechanism that satisfies the requirements of grid and also extends this "pass-along" property of a parameter to AORs *without resorting to UAs handling Route headers*, I am generally supportive. I would want to include this mechanism either in the GRUU draft itself or in a small document that GRUU normatively references and that any GRUU-supporting device MUST implement. thanks, -rohan On 10/25/06, Eric Rescorla wrote: > "Rohan Mahy" writes: > > On 10/25/06, Eric Rescorla wrote: > >> Right, that's just one way of implementing. My point in responding to your > >> message was that a parameter that is GRUU-only to do a task that is > >> applicable outside of GRUU is a Bad Thing. > > > > Postponing this *agreed-upon* functionality for GRUU to depend on a > > brand-new untested mechanism is a MUCH WORSE Thing. > > I don't agree, but I think we're talking past each other here. > > Prior to this change GRUU defined a mechanism whereby the UAC could > add a disambiguator to a GRUU. My point is that whatever mechanism > we choose should have applicability outside of GRUU. > Are you objecting to this? If so, why? > > I appreciate that you think the particular proposed mechanism to attack > this problem is bad, but that's not what I'm arguing for here... > > -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 Thu Oct 26 14:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdALc-0001SH-Lk; Thu, 26 Oct 2006 14:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdALa-0001SB-OT for sip@ietf.org; Thu, 26 Oct 2006 14:52:58 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdALZ-00013C-Ee for sip@ietf.org; Thu, 26 Oct 2006 14:52:58 -0400 Received: from [64.101.181.168] (dhcp-64-101-181-168.cisco.com [64.101.181.168]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9QHuPvL024239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 12:56:27 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DB7781C@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DB7781C@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Thu, 26 Oct 2006 13:52:53 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF SIP List , 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 On Oct 25, 2006, at 3:53 PM, Francois Audet wrote: > > Dean is basically saying that sips should be able to mean other > protocols than TLS (e.g., IPsec). So pretty much the opposite of > your points in this email. > I'm saying that as long as we have transports other than TCP, and with TLS implementations being in the minority, that SIPS should be able to use other security encapsulations that provide equivalent security, including DTLS and IPSEC. Of course, I'd also be happy to deprecate UDP and go with TLS only. -- 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 Oct 26 15:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdATz-0003XR-Ho; Thu, 26 Oct 2006 15:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdATy-0003XM-9p for sip@ietf.org; Thu, 26 Oct 2006 15:01:38 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdATw-00026v-Gv for sip@ietf.org; Thu, 26 Oct 2006 15:01:38 -0400 Received: by ug-out-1314.google.com with SMTP id 72so395094ugd for ; Thu, 26 Oct 2006 12:01:35 -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=i+fB3IDMqps0D6zF4SIbVew2eBZszv0JEEdaZQ0FxejMzR0kYkb3lcXAvORWcXvL2PND4LvtoAJHEgSuMri0V8EarH2+NaTvvipId07lv4KKdRyslG4cDsH68W70k3hHiB45UcGT6dRZ67Yf5hCiX9mfWTBuR6nknOQpMVn4W7w= Received: by 10.78.201.8 with SMTP id y8mr2393404huf; Thu, 26 Oct 2006 12:01:34 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Thu, 26 Oct 2006 12:01:34 -0700 (PDT) Message-ID: <953beacc0610261201s200d1874l8f96bc7543a4b29b@mail.gmail.com> Date: Thu, 26 Oct 2006 12:01:34 -0700 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <4540D21F.5000102@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <453DA2F3.1070009@cisco.com> <953beacc0610241630i68941222p99859339e2d14bc@mail.gmail.com> <4540D21F.5000102@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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, comments inline. On 10/26/06, Jonathan Rosenberg wrote: > inline. > > Rohan Mahy wrote: > > > > I think these changes definitely improved readability. > > > >> * added "anonymous gruu", known as temporary gruu. A temporary GRUU is > >> assigned when you first register a contact, and an additional one is > >> created on each refresh. All of the ones accumulated over the > >> lifetime of the registration remain valid. Each of them obfuscate > >> the AOR and instance ID. Added a description of a stateless > >> algorithm for computing these. Lengthy discussion on the privacy > >> implications of using them. > > > > > > I just reviewed the extremely lengthy thread on GRUU privacy and have > > yet to see anything resembling consensus on which privacy or > > limited-user requirements we are trying to add here. > > Well we had consensus I think on trying to do as good as rfc3261 alone. > There was some debate on whether this would in fact require you to > change Contact URI on a call by call basis (since you could do that with > rfc3261). But there was consensus on that requirement I thought. Maybe you had a consenus on a phone call, but I could not find more than a handful of people agreeing with this principle in the long thread. > Furthermore I > > expect that the mechanism provided could be abused by UAs that want a > > private per call for example, creating a lot of registration thrash, > > jeopardizing the avalanche restart prevention work in outbound. > > Per my other note, getting a different gruu per call does not require > extra registrations. > A UA with an objective of being malicious, and placing load on the > server, can re-register a lot with or without the gruu spec. My use case was separate a Contact URI per unrelated call, which as you point out can be done in RFC3261. I'm not considering the UA being malicious. > >> * removed completely the grid concept and associated processing. The > >> plan is to instead use loose routing or an alternative like it which > >> would allow a UA to add params to an AOR or a GRUU and get them back > >> in a request it receives. > > > > > > We had a requirement in the GRUU draft to be able to manufacture a > > whole family of GRUU. Grid satisfied this requirement. I STRONGLY > > object to any attempt to make this functionality depend on an untried, > > substantially risky new mechanism. I will take this to a process > > appeal if necessary. > > During his review, ekr raised the issue that this was really a general > issue and that the proposed solution was highly specific to gruu, and > that a better, more general purpose solution was reqiured (one that > allowed you to manufacture identities against your AOR too). This was a > good point and there was consensus to do a more general solution. Thus, > the functionality was pulled from GRUU, and I submitted an individual > I-D proposing a solution. You are welcome to submit a draft with your > solution. > > Are you objecting to the proposed mechanism, or objecting to making it > more general purpose and in a separate spec? I am objecting to removing this functionality from GRUU. I do not object to renaming the grid parameter in the GRUU spec, making this "passthru" behavior apply to AORs on supporting proxies, or even putting this general functionality in a seperate section of GRUU. If the WG agrees that the general solution is compelling enough to move this to a separate WG draft and send it to WGLC at the same time, I am OK with that too as long as the general purpose solution is mandatory to implement if you implement GRUU. > >> * removed bit about registering different contacts to each AOR when a > >> UA has multiple AOR; will leave that to the UA loose route spec > > > > > > Again, I object to making this document depend on the UA loose routing > > spec. If you want to tone down the language, I propose something like > > this: > > > > "Note a User Agent with multiple AORs needs to insure that it can > > distinguish requests to each AOR. One way to insure this property is > > to use a unique Contact URI per AOR." > > The GRUU spec more or less talks about doing this, but not in a > normative fashion as it did in -10. The following text appears in -11: > > When a UA receives a request, the GRUU placed into the Contact header > field of a 2xx response SHOULD be the one associated with the AOR or > GRUU to which the request was most recently targeted. There are > several ways to determine the AOR or GRUU to which a request was > sent. For example, if a UA registered a different contact to each > AOR (by using a different user part of the URI), the Request-URI > (which contains that contact) will indicate the AOR. > > are you objecting to this? I think this is a minor detail. I prefer just saying that UAs need to do this. SHOULD implies wiggle room that I don't feel is appropriate. 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 Thu Oct 26 16:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBOt-0004mV-4k; Thu, 26 Oct 2006 16:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMt-00020B-0I; Thu, 26 Oct 2006 15:58:23 -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 1GdBFt-0007Jy-Ee; Thu, 26 Oct 2006 15:51:09 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GdBFs-0005xo-Ri; Thu, 26 Oct 2006 15:51:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D444417602; Thu, 26 Oct 2006 19:50:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEu-0005L0-Bi; Thu, 26 Oct 2006 15:50:08 -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, 26 Oct 2006 15:50:08 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-11.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-11.txt Pages : 35 Date : 2006-10-26 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 registrar 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-11.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-11.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-11.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-10-26121733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26121733.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 Oct 26 16:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBWv-0006f9-6k; Thu, 26 Oct 2006 16:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBWo-0006bl-TK for sip@ietf.org; Thu, 26 Oct 2006 16:08:39 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBWI-0000sR-Av for sip@ietf.org; Thu, 26 Oct 2006 16:08:37 -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 k9QK7sK09112; Thu, 26 Oct 2006 16:07: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] RE: TLS meaning Date: Thu, 26 Oct 2006 15:07:25 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CA84@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5MAAhzZpRzqR3RDCZAXbzN7aUxQACiuIQ From: "Samir Srivastava" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: IETF SIP List , 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 What about DCCP in Page mode IM that has the congestion control. You can run DTLS over that too. Thx Samir > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, October 26, 2006 11:53 AM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List; Aki Niemi > Subject: Re: [Sip] RE: TLS meaning >=20 >=20 > On Oct 25, 2006, at 3:53 PM, Francois Audet wrote: >=20 > > > > Dean is basically saying that sips should be able to mean other > > protocols than TLS (e.g., IPsec). So pretty much the opposite of > > your points in this email. > > >=20 > I'm saying that as long as we have transports other than TCP, and > with TLS implementations being in the minority, that SIPS should be > able to use other security encapsulations that provide equivalent > security, including DTLS and IPSEC. >=20 > Of course, I'd also be happy to deprecate UDP and go with TLS only. >=20 > -- > Dean >=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 Thu Oct 26 16:48:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC6e-0002V4-J5; Thu, 26 Oct 2006 16:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-00021t-J4; Thu, 26 Oct 2006 15:58:24 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBEv-0007Ek-Jm; Thu, 26 Oct 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8E41526E5F; Thu, 26 Oct 2006 19:50:09 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEv-0005NA-Ew; Thu, 26 Oct 2006 15:50:09 -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, 26 Oct 2006 15:50:09 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-saml-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 : SIP SAML Profile and Binding Author(s) : H. Tschofenig, et al. Filename : draft-ietf-sip-saml-01.txt Pages : 53 Date : 2006-10-26 This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-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-saml-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-saml-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-10-26144435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-saml-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-saml-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26144435.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 Oct 26 17:18:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCaH-0006tH-Ry; Thu, 26 Oct 2006 17:16:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCaF-0006sr-PC for sip@ietf.org; Thu, 26 Oct 2006 17:16:15 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCZu-0007pH-Sq for sip@ietf.org; Thu, 26 Oct 2006 17:16:15 -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 k9QLFq718971; Thu, 26 Oct 2006 17:15: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 Date: Thu, 26 Oct 2006 16:15:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> In-Reply-To: <05F32587-3EAE-44AB-9D06-1D0A31273739@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS meaning Thread-Index: Acb5L0HXAOSMrOyyRg+0tImXtI5biAAEmtIQ From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: IETF SIP List Subject: [Sip] RE: TLS meaning X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Dean, I'm OK with using other protocols (including DTLS and IPsec) to secure signalling, but I don't see why you'd need to use SIPS for that. I'd argue that using SIP for that instead of sips is better. Easier to=20 implement. No arcane rules as for SIPS.=20 If this was to be redone, I wouldn't use SIPS at all. I believe it was a mistake in the first place. But at the last meeting, we decided it was too late to "deprecate it", and I believe we also decided that it would mean what was said in RFC 3261. We would just clarify the confusion around it. That doesn't mean that we should INCREASE the role of sips to other protocols like DTLS and IPsec (and whatever). My take is that if you don't use TLS, you wouldn't use SIPS. I'd rather we use a Require header for that (for example). And then eventually, we'd outgrow sips entirely. To me, a two step approach like this is (a) backward compatible and doesn't require an overhaul of RFC 3261, and (b) allows to fix the immediate problem of TLS-only SIPS, while giving us more time for a more general solution. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, October 26, 2006 11:48 AM > To: Audet, Francois (SC100:3055) > Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary=20 > (RICH2:AR00); Gonzalo Camarillo; IETF SIP List > Subject: Re: TLS meaning >=20 >=20 > On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: >=20 > > So, to summarize, you are NOT happy with the current consensus, and=20 > > you are proposing something completely different, i.e.,=20 > that instead=20 > > of just the current cludgy "last-hop exception rule", we also add a=20 > > new "first-hop exception" (and I would imagine a new "any hop=20 > > exception" rule)? > > >=20 > Good summary. >=20 >=20 >=20 > > Unlike the current "last hop exception rule" which imposes=20 > absolutely=20 > > no security requirements, your "any hop exception rule"=20 > would change=20 > > this it to a "decent security equivalent to TLS" rule. > > >=20 > Yep. >=20 > > This would entail finding all the instances of "TLS" in RFC=20 > 3261 and=20 > > make the according changes. > > >=20 > That's one way to approach it. Another way to do it would be another =20 > RFC that extends 3261 and says basically "Wherever RFC 321 says TLS, =20 > please substitute . . . " >=20 > > This is a gigantic change from RFC 2961. I don't think it is =20 > > reasonable. > > >=20 > Doesn't have to be reasonable if it's necessary. >=20 > > It is orders of magnitude bigger than what is discussed in > > draft-audet-sip-sips-guidelines which does NOT attempt to redefine > > the meaning of sips, and does NOT invalidate RFC 3261. > > >=20 > Not saying your draft isn't needed. Just saying it isn't enough to =20 > really fix the problem. >=20 >=20 > > My take is that using other protocols than TLS is perfectly fine. > > However, > > it does not mean that we should be using sips in that case.=20 > I'd argue > > that > > using sip is perfectly fine in those cases. > > > > If a network for example relies on IPsec, maybe there is no=20 > need to =20 > > use > > sips at all. > > >=20 > So how would you propose that a user say "I expect you to ship this =20 > request and an responses to it over secured links, and if you can't, =20 > I want you to reject it" without using sips:? >=20 >=20 > > I think we need to be pragmatic here. We can not invalidate huge =20 > > chunks > > of > > RFC 3261 in the way you are proposing. >=20 > I believe otherwise. >=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 sip-implementors@cs.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 Oct 26 17:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCeY-0001DZ-Eq; Thu, 26 Oct 2006 17:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBSQ-0001Lt-4U for sip@ietf.org; Thu, 26 Oct 2006 16:04:06 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdBS0-0000Lh-AU for sip@ietf.org; Thu, 26 Oct 2006 16:04:05 -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 k9QK3bK08408; Thu, 26 Oct 2006 16:03:37 -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] Fwd: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Date: Thu, 26 Oct 2006 15:03:28 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CA6F@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Thread-Index: Acb3zWNEqdvlPd77Rc+SrWGYMucUmABamGfA From: "Samir Srivastava" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 > Given that the current TLS usage doesn't actually assure anything > about the cyphersuite and authentication mechanism employed at each > hop other than the presumption that the proxies involved are going to > try and make good decisions (which is not completely unreasonable, > according to our security advisor), why can't we also presume that > those same proxies can make equally good decisions about alternative > transport encapsulations, such as IPSEC? I am in *complete disagreement* with the security advisor here. I have presented more than enough evidence to have the cipher-suite and secure protocol being exposed to the SIP. This is in accordance with the purist view of internet. Believe it or not, I am sick so my cipher-suite draft is not submitted and still recovering. I will be commenting on the deprecation / surgery stuff in the separate thread. Dean, you yourself argued long time back even before the Dave Oran's comment on the cipher-suite etc in the last hop in IMS where users are open to MITM=20 http://www1.ietf.org/mail-archive/web/sip/current/msg13337.html=20 BTW, I like sometimes (without the *big* hat) purists Deanism views .. 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 Thu Oct 26 17:53:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdD8a-0001M1-VM; Thu, 26 Oct 2006 17:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCzK-0003yv-1i for sip@ietf.org; Thu, 26 Oct 2006 17:42:10 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCp9-0001d0-A8 for sip@ietf.org; Thu, 26 Oct 2006 17:31:40 -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 k9QLVCK04607; Thu, 26 Oct 2006 17:31:12 -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] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Date: Thu, 26 Oct 2006 16:30:56 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CC34@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: TLS meaning (was Re: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt) Thread-Index: Acb38t6EBpyTx+atQhyaT9Pw1CLEEQBUa4bQAABaYdA= From: "Samir Srivastava" To: "Samir Srivastava" , "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Adam Roach , Robert Sparks , Paul Kyzivat , Gonzalo Camarillo , IETF SIP List , Mary Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 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 > Actually, HTTPS means you have TLS all the way to the far end, with no > "proxy MITM" weakness. SIPS doesn't mean that. >=20 > And IMAPS and POPS both mean SSL, not TLS, in common practice. >=20 > But SMTP, which uses a hop-by-hop relayance model much more similar to > SIP than HTTP is, doesn't have an SMPTS to insist on hop-by-hop=20 > security, because that would just be silly for email (as it is silly=20 > for SIP, from a security perspective). >=20 Great Example. In HTTP there is very thin line between the resource and routing. So we don't see these problems. Purists are needed to make diamonds ..... =20 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 Thu Oct 26 18:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLX-0003gr-5r; Thu, 26 Oct 2006 18:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLC-0002bY-RV for sip@ietf.org; Thu, 26 Oct 2006 18:04:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdD8W-0005cS-7b for sip@ietf.org; Thu, 26 Oct 2006 17:51: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 k9QLpbK06665; Thu, 26 Oct 2006 17:51:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: TLS meaning Date: Thu, 26 Oct 2006 16:51:36 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CCAA@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5MAAhzZpRzqR3RDCZAXbzN7aUxQAC1aHw From: "Samir Srivastava" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: IETF SIP List , 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: , Content-Type: multipart/mixed; boundary="===============1481303979==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1481303979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F948.E90369B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F948.E90369B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Surgery / Change Criterias=20 =20 1. Changing the internet at the core is practically impossible. 2. Changing the internet at the edge is lethargically slow. 3. Interface between the network and the internetwork can be changed. =20 The above view was shared with Bruce Young (My earlier VP at Level 3) for working on the congestion (Event based heart beat, IP level congestion etc I will be reopening), and recently the Phillip Baker also shared the same views for changing the S/MIME =20 So now view it within the presepective of the SIP. SIP is nowhere ubiquitous as compared to IP.=20 =20 We have very nice tool available to us Proxy-Require (tcp) to move gradually to reliable (DCCP open question) transports..... Need of the hour is to deprecate UDP all-together. Write one RFC which states the issues with UDP and recommends it is bad for your network health and use at your own risk.=20 =20 =20 SIPS: =20 Internet is always evoloving. And it should be noted that standards are called only "REQUEST FOR COMMENTS". Consensus achieved in *A* meeting is not a complete binding. For the attorney's kind of arguments Refer following from section 5.2 http://www.ietf.org/tao.html =20 =20 "One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. FinallyFrom sip-bounces@ietf.org Thu Oct 26 18:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLX-0003gr-5r; Thu, 26 Oct 2006 18:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLC-0002bY-RV for sip@ietf.org; Thu, 26 Oct 2006 18:04:46 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdD8W-0005cS-7b for sip@ietf.org; Thu, 26 Oct 2006 17:51: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 k9QLpbK06665; Thu, 26 Oct 2006 17:51:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RE: TLS meaning Date: Thu, 26 Oct 2006 16:51:36 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CCAA@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5MAAhzZpRzqR3RDCZAXbzN7aUxQAC1aHw From: "Samir Srivastava" To: "Dean Willis" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: IETF SIP List , 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: , Content-Type: multipart/mixed; boundary="===============1481303979==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1481303979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F948.E90369B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F948.E90369B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Surgery / Change Criterias=20 =20 1. Changing the internet at the core is practically impossible. 2. Changing the internet at the edge is lethargically slow. 3. Interface between the network and the internetwork can be changed. =20 The above view was shared with Bruce Young (My earlier VP at Level 3) for working on the congestion (Event based heart beat, IP level congestion etc I will be reopening), and recently the Phillip Baker also shared the same views for changing the S/MIME =20 So now view it within the presepective of the SIP. SIP is nowhere ubiquitous as compared to IP.=20 =20 We have very nice tool available to us Proxy-Require (tcp) to move gradually to reliable (DCCP open question) transports..... Need of the hour is to deprecate UDP all-together. Write one RFC which states the issues with UDP and recommends it is bad for your network health and use at your own risk.=20 =20 =20 SIPS: =20 Internet is always evoloving. And it should be noted that standards are called only "REQUEST FOR COMMENTS". Consensus achieved in *A* meeting is not a complete binding. For the attorney's kind of arguments Refer following from section 5.2 http://www.ietf.org/tao.html =20 =20 "One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere" =20 SIPS is not *DEPLOYED*. (Pl correct me, if I am wrong). If things are not deployed then we have a free ride to deprecate it. I will be sending the occurences of SIPS in the existing RFC in a separate email. Write one RFC which updates all these existing RFC stating that "It updates with a generic statements in the contents. And then have a clean solution. =20 We need to have a puristic view. We have a mud with us. Whatever (Diamond etc) you put in the mud, it will be muddy only... We need to clean up the mud... We have made already so many mistakes on SIPS..(Not even putting one fact at one place in documenting itself...). =20 BTW, If you agree on cipher-suites, then Proxy-Require to enforce cipher-suites makes the SIPS redundant all-together. If anybody has any ENGINEERING arguments to keep it, I am most willing to hear it.=20 =20 Thx Samir =20 =20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, October 26, 2006 11:53 A To: Audet, Francois (SC100:3055) Cc: IETF SIP List; Aki Niemi Subject: Re: [Sip] RE: TLS meaning =20 =20 On Oct 25, 2006, at 3:53 PM, Francois Audet wrote: =20 >=20 > Dean is basically saying that sips should be able to mean other=20 > protocols than TLS (e.g., IPsec). So pretty much the opposite of your=20 > points in this email. >=20 =20 I'm saying that as long as we have transports other than TCP, and with TLS implementations being in the minority, that SIPS should be able to use other security encapsulations that provide equivalent security, including DTLS and IPSEC. =20 Of course, I'd also be happy to deprecate UDP and go with TLS only. =20 -- Dean =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 ------_=_NextPart_001_01C6F948.E90369B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Surgery / Change Criterias

 

1. Changing the internet at the core is practically = impossible.

2. Changing the internet at the edge is lethargically = slow.

3. Interface between the network and the internetwork can be = changed.<, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere" =20 SIPS is not *DEPLOYED*. (Pl correct me, if I am wrong). If things are not deployed then we have a free ride to deprecate it. I will be sending the occurences of SIPS in the existing RFC in a separate email. Write one RFC which updates all these existing RFC stating that "It updates with a generic statements in the contents. And then have a clean solution. =20 We need to have a puristic view. We have a mud with us. Whatever (Diamond etc) you put in the mud, it will be muddy only... We need to clean up the mud... We have made already so many mistakes on SIPS..(Not even putting one fact at one place in documenting itself...). =20 BTW, If you agree on cipher-suites, then Proxy-Require to enforce cipher-suites makes the SIPS redundant all-together. If anybody has any ENGINEERING arguments to keep it, I am most willing to hear it.=20 =20 Thx Samir =20 =20 =20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, October 26, 2006 11:53 A To: Audet, Francois (SC100:3055) Cc: IETF SIP List; Aki Niemi Subject: Re: [Sip] RE: TLS meaning =20 =20 On Oct 25, 2006, at 3:53 PM, Francois Audet wrote: =20 >=20 > Dean is basically saying that sips should be able to mean other=20 > protocols than TLS (e.g., IPsec). So pretty much the opposite of your=20 > points in this email. >=20 =20 I'm saying that as long as we have transports other than TCP, and with TLS implementations being in the minority, that SIPS should be able to use other security encapsulations that provide equivalent security, including DTLS and IPSEC. =20 Of course, I'd also be happy to deprecate UDP and go with TLS only. =20 -- Dean =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 ------_=_NextPart_001_01C6F948.E90369B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Surgery / Change Criterias

 

1. Changing the internet at the core is practically = impossible.

2. Changing the internet at the edge is lethargically = slow.

3. Interface between the network and the internetwork can be = changed.

 

The above view was shared with Bruce Young (My earlier VP at = Level 3) for working on the congestion (Event based heart beat, IP level = congestion etc I will be reopening), and recently the Phillip Baker also shared the = same views for changing the S/MIME

 

So now view it within the presepective of the SIP. SIP is = nowhere ubiquitous as compared to IP.

 

We have very nice tool available to us Proxy-Require (tcp) to = move gradually to reliable (DCCP open question) transports..... Need of the = hour is to deprecate UDP all-together. Write one RFC which states the issues = with UDP and recommends it is bad for your network health and use at your own risk. =

 

 

SIPS:

 

Internet is always evoloving. And it should be noted that = standards are called only "REQUEST FOR COMMENTS". Consensus achieved in *A* = meeting is not a complete binding. For the attorney's kind of arguments Refer = following from section 5.2 http://www.ietf.org/tao.html  

 

"One fact that confuses many novices is that the = face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at = a face-to-face meeting must also gain consensus on the WG mailing list. = There are numerous examples of important decisions made in WG meetings that are = later overturned on the mailing list, often because someone who couldn't = attend the meeting pointed out a serious flaw in the logic used to come to the = decision. Finally, WG meetings aren't "drafting sessions", as they are = in some other standards bodies: in the IETF, drafting is done = elsewhere"

 

SIPS is not *DEPLOYED*. (Pl correct me, if I am wrong). If = things are not deployed then we have a free ride to deprecate it. I will be sending = the occurences of SIPS in the existing RFC in a separate email. Write one = RFC which updates all these existing RFC stating that "It updates <list of = RFC ...> with a generic statements in the contents. And then have a clean solution.

 

The above view was shared with Bruce Young (My earlier VP at = Level 3) for working on the congestion (Event based heart beat, IP level = congestion etc I will be reopening), and recently the Phillip Baker also shared the = same views for changing the S/MIME

 

So now view it within the presepective of the SIP. SIP is = nowhere ubiquitous as compared to IP.

 

We have very nice tool available to us Proxy-Require (tcp) to = move gradually to reliable (DCCP open question) transports..... Need of the = hour is to deprecate UDP all-together. Write one RFC which states the issues = with UDP and recommends it is bad for your network health and use at your own risk. =

 

 

SIPS:

 

Internet is always evoloving. And it should be noted that = standards are called only "REQUEST FOR COMMENTS". Consensus achieved in *A* = meeting is not a complete binding. For the attorney's kind of arguments Refer = following from section 5.2 http://www.ietf.org/tao.html  

 

"One fact that confuses many novices is that the = face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at = a face-to-face meeting must also gain consensus on the WG mailing list. = There are numerous examples of important decisions made in WG meetings that are = later overturned on the mailing list, often because someone who couldn't = attend the meeting pointed out a serious flaw in the logic used to come to the = decision. Finally, WG meetings aren't "drafting sessions", as they are = in some other standards bodies: in the IETF, drafting is done = elsewhere"

 

SIPS is not *DEPLOYED*. (Pl correct me, if I am wrong). If = things are not deployed then we have a free ride to deprecate it. I will be sending = the occurences of SIPS in the existing RFC in a separate email. Write one = RFC which updates all these existing RFC stating that "It updates <list of = RFC ...> with a generic statements in the contents. And then have a clean solution.

 

We need to have a puristic view. We have a mud with us. Whatever (Diamond etc) you put in the mud, it will be muddy only... We need to = clean up the mud... We have made already so many mistakes on SIPS..(Not even = putting one fact at one place in documenting = itself...).

 

BTW, If you agree on cipher-suites, then Proxy-Require to = enforce cipher-suites makes the SIPS redundant all-together. If anybody has any = ENGINEERING arguments to keep it, I am most willing to hear it. =

 

Thx

Samir

 

 

 

-----Original Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com] =

Sent: Thursday, October 26, 2006 11:53 = A

To: Audet, Francois (SC100:3055)

Cc: IETF SIP List; Aki Niemi

Subject: Re: [Sip] RE: TLS meaning

 

 

On Oct 25, 2006, at 3:53 PM, Francois Audet = wrote:

 

> 

> Dean is basically saying that sips should be able to mean = other

> protocols than TLS (e.g., IPsec). So pretty much the = opposite of your

> points in this email.

 

We need to have a puristic view. We have a mud with us. Whatever (Diamond etc) you put in the mud, it will be muddy only... We need to = clean up the mud... We have made already so many mistakes on SIPS..(Not even = putting one fact at one place in documenting = itself...).

 

BTW, If you agree on cipher-suites, then Proxy-Require to = enforce cipher-suites makes the SIPS redundant all-together. If anybody has any = ENGINEERING arguments to keep it, I am most willing to hear it. =

 

Thx

Samir

 

 

 

-----Original Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com] =

Sent: Thursday, October 26, 2006 11:53 = A

To: Audet, Francois (SC100:3055)

Cc: IETF SIP List; Aki Niemi

Subject: Re: [Sip] RE: TLS meaning

 

 

On Oct 25, 2006, at 3:53 PM, Francois Audet = wrote:

 

> 

> Dean is basically saying that sips should be able to mean = other

> protocols than TLS (e.g., IPsec). So pretty much the = opposite of your

> points in this email.

> 

 

I'm saying that as long as we have transports other than TCP, = and with TLS implementations being in the minority, that SIPS should be able to = use other security encapsulations that provide equivalent security, = including DTLS and IPSEC.

 

Of course, I'd also be happy to deprecate UDP and go with TLS = only.

 

--

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

------_=_NextPart_001_01C6F948.E90369B5-- --===============1481303979== 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 --===============1481303979==-- From sip-bounces@ietf.org Thu Oct 26 18:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLa-0003sV-3n; Thu, 26 Oct 2006 18:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLD-0002Ej-9y for sip@ietf.org; Thu, 26 Oct 2006 18:04:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdD8L-0005at-9X for sip@ietf.org; Thu, 26 Oct 2006 17:51:31 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2006 14:51:28 -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 k9QLpS4M023666; Thu, 26 Oct 2006 14:51:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QLpSbF020870; Thu, 26 Oct 2006 14:51:28 -0700 (PDT) Received: from [10.7.1.104] (sjc-vpn6-233.cisco.com [10.21.120.233]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9QLcjbu023351; Thu, 26 Oct 2006 14:38:56 -0700 Message-ID: <45412DD8.4090207@cisco.com> Date: Thu, 26 Oct 2006 14:51:20 -0700 Frome=3D'font-size: 10.0pt'>> 

 

I'm saying that as long as we have transports other than TCP, = and with TLS implementations being in the minority, that SIPS should be able to = use other security encapsulations that provide equivalent security, = including DTLS and IPSEC.

 

Of course, I'd also be happy to deprecate UDP and go with TLS = only.

 

--

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

------_=_NextPart_001_01C6F948.E90369B5-- --===============1481303979== 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 --===============1481303979==-- From sip-bounces@ietf.org Thu Oct 26 18:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLa-0003sV-3n; Thu, 26 Oct 2006 18:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLD-0002Ej-9y for sip@ietf.org; Thu, 26 Oct 2006 18:04:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdD8L-0005at-9X for sip@ietf.org; Thu, 26 Oct 2006 17:51:31 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 Oct 2006 14:51:28 -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 k9QLpS4M023666; Thu, 26 Oct 2006 14:51:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9QLpSbF020870; Thu, 26 Oct 2006 14:51:28 -0700 (PDT) Received: from [10.7.1.104] (sjc-vpn6-233.cisco.com [10.21.120.233]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9QLcjbu023351; Thu, 26 Oct 2006 14:38:56 -0700 Message-ID: <45412DD8.4090207@cisco.com> Date: Thu, 26 Oct 2006 14:51:20 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-8.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4605; t=1161899488; x=1162763488; c=relaxed/relaxed; s=sjdkim8002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=LdibCgEQUIm6fXK8YZLntcO0uszHB6aeqEJDqZ0+j8dU5awgBk8Nyze1cugYT2xmDXvTNuWR byufw0I5vSTzeBOuCcJmdmX5E+xVsvhTT9feJUI3mPoeOeDSYvTBgsuz; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 Francois Audet wrote: >Hi Dean, > >I'm OK with using other protocols (including DTLS and IPsec) to secure >signalling, but I don't see why you'd need to use SIPS for that. > >I'd argue that using SIP for that instead of sips is better. Easier to >implement. No arcane rules as for SIPS. > >If this was to be redone, I wouldn't use SIPS at all. I believe it was a >mistake >in the first place. > >But at the last meeting, we decided it was too late to "deprecate it", >and I believe >we also decided that it would mean what was said in RFC 3261. We would >just >clarify the confusion around it. > > It's never too late to deprecate something, especially when nobody agrees as to what it means. In fact, given the confusion and the general lack of consensus, the mosty prudent thing would be *to* excise its use to hopefully force the cancer into remission. I mean, what's the real problem here: "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a SIPS URI any different from a SIP URI" Doesn't that just about do what you can to cut it out? Mike >That doesn't mean that we should INCREASE the role of sips to other >protocols >like DTLS and IPsec (and whatever). > >My take is that if you don't use TLS, you wouldn't use SIPS. I'd rather >we >use a Require header for that (for example). > >And then eventually, we'd outgrow sips entirely. > >To me, a two step approach like this is (a) backward compatible and >doesn't >require an overhaul of RFC 3261, and (b) allows to fix the immediate >problem >of TLS-only SIPS, while giving us more time for a more general solution. > > > > > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Thursday, October 26, 2006 11:48 AM >>To: Audet, Francois (SC100:3055) >>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary >>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List >>Subject: Re: TLS meaning >> >> >>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: >> >> >> >>>So, to summarize, you are NOT happy with the current consensus, and >>>you are proposing something completely different, i.e., >>> >>> >>that instead >> >> >>>of just the current cludgy "last-hop exception rule", we also add a >>>new "first-hop exception" (and I would imagine a new "any hop >>>exception" rule)? >>> >>> >>> >>Good s: 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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-8.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4605; t=1161899488; x=1162763488; c=relaxed/relaxed; s=sjdkim8002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=LdibCgEQUIm6fXK8YZLntcO0uszHB6aeqEJDqZ0+j8dU5awgBk8Nyze1cugYT2xmDXvTNuWR byufw0I5vSTzeBOuCcJmdmX5E+xVsvhTT9feJUI3mPoeOeDSYvTBgsuz; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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 Francois Audet wrote: >Hi Dean, > >I'm OK with using other protocols (including DTLS and IPsec) to secure >signalling, but I don't see why you'd need to use SIPS for that. > >I'd argue that using SIP for that instead of sips is better. Easier to >implement. No arcane rules as for SIPS. > >If this was to be redone, I wouldn't use SIPS at all. I believe it was a >mistake >in the first place. > >But at the last meeting, we decided it was too late to "deprecate it", >and I believe >we also decided that it would mean what was said in RFC 3261. We would >just >clarify the confusion around it. > > It's never too late to deprecate something, especially when nobody agrees as to what it means. In fact, given the confusion and the general lack of consensus, the mosty prudent thing would be *to* excise its use to hopefully force the cancer into remission. I mean, what's the real problem here: "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a SIPS URI any different from a SIP URI" Doesn't that just about do what you can to cut it out? Mike >That doesn't mean that we should INCREASE the role of sips to other >protocols >like DTLS and IPsec (and whatever). > >My take is that if you don't use TLS, you wouldn't use SIPS. I'd rather >we >use a Require header for that (for example). > >And then eventually, we'd outgrow sips entirely. > >To me, a two step approach like this is (a) backward compatible and >doesn't >require an overhaul of RFC 3261, and (b) allows to fix the immediate >problem >of TLS-only SIPS, while giving us more time for a more general solution. > > > > > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Thursday, October 26, 2006 11:48 AM >>To: Audet, Francois (SC100:3055) >>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary >>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List >>Subject: Re: TLS meaning >> >> >>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: >> >> >> >>>So, to summarize, you are NOT happy with the current consensus, and >>>you are proposing something completely different, i.e., >>> >>> >>that instead >> >> >>>of just the current cludgy "last-hop exception rule", we also add a >>>new "first-hop exception" (and I would imagine a new "any hop >>>exception" rule)? >>> >>> >>> >>Good summary. >> >> >> >> >> >>>Unlike the current "last hop exception rule" which imposes >>> >>> >>absolutely >> >> >>>no security requirements, your "any hop exception rule" >>> >>> >>would change >> >> >>>this it to a "decent security equivalent to TLS" rule. >>> >>> >>> >>Yep. >> >> >> >>>This would entail finding all the instances of "TLS" in RFC >>> >>> >>3261 and >> >> >>>make the according changes. >>> >>> >>> >>That's one way to approach it. Another way to do it would be another >>RFC that extends 3261 and says basically "Wherever RFC 321 says TLS, >>please substitute . . . " >> >> >> >>>This is a gigantic change from RFC 2961. I don't think it is >>>reasonable. >>> >>> >>> >>Doesn't have to be reasonable if it's necessary. >> >> >> >>>It is orders of magnitude bigger than what is discussed in >>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine >>>the meaning of sips, and does NOT invalidate RFC 3261. >>> >>> >>> >>Not saying your draft isn't needed. Just saying it isn't enough to >>really fix the problem. >> >> >> >> >>>My take is that using other protocols than TLS is perfectly fine. >>>However, >>>it does not mean that we should be using sips in that case. >>> >>> >>I'd argue >> >> >>>that >>>using sip is perfectly fine in those cases. >>> >>>If a network for example relies on IPsec, maybe there is no >>> >>> >>need to >> >> >>>use >>>sips at all. >>> >>> >>> >>So how would you propose that a user say "I expect you to ship this >>request and an responses to it over secured links, and if you can't, >>I want you to reject it" without using sips:? >> >> >> >> >>>I think we need to be pragmatic here. We can not invalidate huge >>>chunks >>>of >>>RFC 3261 in the way you are proposing. >>> >>> >>I believe otherwise. >> >>-- >>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 ummary. >> >> >> >> >> >>>Unlike the current "last hop exception rule" which imposes >>> >>> >>absolutely >> >> >>>no security requirements, your "any hop exception rule" >>> >>> >>would change >> >> >>>this it to a "decent security equivalent to TLS" rule. >>> >>> >>> >>Yep. >> >> >> >>>This would entail finding all the instances of "TLS" in RFC >>> >>> >>3261 and >> >> >>>make the according changes. >>> >>> >>> >>That's one way to approach it. Another way to do it would be another >>RFC that extends 3261 and says basically "Wherever RFC 321 says TLS, >>please substitute . . . " >> >> >> >>>This is a gigantic change from RFC 2961. I don't think it is >>>reasonable. >>> >>> >>> >>Doesn't have to be reasonable if it's necessary. >> >> >> >>>It is orders of magnitude bigger than what is discussed in >>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine >>>the meaning of sips, and does NOT invalidate RFC 3261. >>> >>> >>> >>Not saying your draft isn't needed. Just saying it isn't enough to >>really fix the problem. >> >> >> >> >>>My take is that using other protocols than TLS is perfectly fine. >>>However, >>>it does not mean that we should be using sips in that case. >>> >>> >>I'd argue >> >> >>>that >>>using sip is perfectly fine in those cases. >>> >>>If a network for example relies on IPsec, maybe there is no >>> >>> >>need to >> >> >>>use >>>sips at all. >>> >>> >>> >>So how would you propose that a user say "I expect you to ship this >>request and an responses to it over secured links, and if you can't, >>I want you to reject it" without using sips:? >> >> >> >> >>>I think we need to be pragmatic here. We can not invalidate huge >>>chunks >>>of >>>RFC 3261 in the way you are proposing. >>> >>> >>I believe otherwise. >> >>-- >>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 Oct 26 18:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDbH-0002GV-5E; Thu, 26 Oct 2006 18:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDah-0001gX-Vn for sip@ietf.org; Thu, 26 Oct 2006 18:20:47 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDQf-0000mF-5x for sip@ietf.org; Thu, 26 Oct 2006 18:10:27 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 479E01E8C28; Thu, 26 Oct 2006 15:10:22 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] Fwd: TLS meaning References: <62B9B0847CC47543B6B3B5E26BD268E60F43CA6F@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Thu, 26 Oct 2006 15:10:22 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F43CA6F@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Thu, 26 Oct 2006 15:03:28 -0500") Message-ID: <86mz7iohip.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: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , 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: > . >> >> Given that the current TLS usage doesn't actually assure anything >> about the cyphersuite and authentication mechanism employed at each >> hop other than the presumption that the proxies involved are going to >> try and make good decisions (which is not completely unreasonable, >> according to our security advisor), why can't we also presume that >> those same proxies can make equally good decisions about alternative >> transport encapsulations, such as IPSEC? > > I am in *complete disagreement* with the security advisor here. I have > presented more than enough evidence to have the cipher-suite and secure > protocol being exposed to the SIP. It would probably be useful here if you were more concrete about what "cipher suite and secure protocol being exposed to the SIP" means. I don't have a problem with including the information about what cipher suite was used in headers the same way it is in RFC822 Received lines. I don't, however, agree that you've presented a good argument that the client's *preferences* should be carried in some header. -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 Thu Oct 26 18:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDcy-0003pf-23; Thu, 26 Oct 2006 18:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDam-0001hD-O6 for sip@ietf.org; Thu, 26 Oct 2006 18:20:52 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDPt-0000ZE-Db for sip@ietf.org; Thu, 26 Oct 2006 18:09:38 -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 k9QM2lr27595; Thu, 26 Oct 2006 18:02:47 -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] RE: TLS meaning Date: Thu, 26 Oct 2006 17:09:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> In-Reply-To: <45412DD8.4090207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5SOmSooX5Pc08Stece7X2zdczIgAAkiow From: "Francois Audet" To: "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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 Mike, that's what we agreed NOT to do at the last meeting. I'm not inventing this: people did not want to deprecate sips.=20 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Thursday, October 26, 2006 2:51 PM > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >Hi Dean, > > > >I'm OK with using other protocols (including DTLS and IPsec)=20 > to secure=20 > >signalling, but I don't see why you'd need to use SIPS for that. > > > >I'd argue that using SIP for that instead of sips is better.=20 > Easier to=20 > >implement. No arcane rules as for SIPS. > > > >If this was to be redone, I wouldn't use SIPS at all. I=20 > believe it was=20 > >a mistake in the first place. > > > >But at the last meeting, we decided it was too late to=20 > "deprecate it",=20 > >and I believe we also decided that it would mean what was=20 > said in RFC=20 > >3261. We would just clarify the confusion around it. > > =20 > > > It's never too late to deprecate something, especially when=20 > nobody agrees as to what it means. In fact, given the=20 > confusion and the general lack of consensus, the mosty=20 > prudent thing would be *to* excise its use to hopefully force=20 > the cancer into remission. >=20 > I mean, what's the real problem here: >=20 > "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a > SIPS URI any different from a SIP URI" >=20 > Doesn't that just about do what you can to cut it out? >=20 > Mike >=20 > >That doesn't mean that we should INCREASE the role of sips to other=20 > >protocols like DTLS and IPsec (and whatever). > > > >My take is that if you don't use TLS, you wouldn't use SIPS.=20 > I'd rather=20 > >we use a Require header for that (for example). > > > >And then eventually, we'd outgrow sips entirely. > > > >To me, a two step approach like this is (a) backward compatible and=20 > >doesn't require an overhaul of RFC 3261, and (b) allows to fix the=20 > >immediate problem of TLS-only SIPS, while giving us more time for a=20 > >more general solution. > > > > > > > > =20 > > > >>-----Original Message----- > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > >>Sent: Thursday, October 26, 2006 11:48 AM > >>To: Audet, Francois (SC100:3055) > >>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary=20 > >>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List > >>Subject: Re: TLS meaning > >> > >> > >>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: > >> > >> =20 > >> > >>>So, to summarize, you are NOT happy with the current=20 > consensus, and=20 > >>>you are proposing something completely different, i.e., > >>> =20 > >>> > >>that instead > >> =20 > >> > >>>of just the current cludgy "last-hop exception rule", we=20 > also add a=20 > >>>new "first-hop exception" (and I would imagine a new "any hop=20 > >>>exception" rule)? > >>> > >>> =20 > >>> > >>Good summary. > >> > >> > >> > >> =20 > >> > >>>Unlike the current "last hop exception rule" which imposes > >>> =20 > >>> > >>absolutely > >> =20 > >> > >>>no security requirements, your "any hop exception rule"=20 > >>> =20 > >>> > >>would change > >> =20 > >> > >>>this it to a "decent security equivalent to TLS" rule. > >>> > >>> =20 > >>> > >>Yep. > >> > >> =20 > >> > >>>This would entail finding all the instances of "TLS" in RFC > >>> =20 > >>> > >>3261 and > >> =20 > >> > >>>make the according changes. > >>> > >>> =20 > >>> > >>That's one way to approach it. Another way to do it would=20 > be another=20 > >>RFC that extends 3261 and says basically "Wherever RFC 321=20 > says TLS,=20 > >>please substitute . . . " > >> > >> =20 > >> > >>>This is a gigantic change from RFC 2961. I don't think it is=20 > >>>reasonable. > >>> > >>> =20 > >>> > >>Doesn't have to be reasonable if it's necessary. > >> > >> =20 > >> > >>>It is orders of magnitude bigger than what is discussed in=20 > >>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine=20 > >>>the meaning of sips, and does NOT invalidate RFC 3261. > >>> > >>> =20 > >>> > >>Not saying your draft isn't needed. Just saying it isn't enough to=20 > >>really fix the problem. > >> > >> > >> =20 > >> > >>>My take is that using other protocols than TLS is perfectly fine. > >>>However, > >>>it does not mean that we should be using sips in that case.=20 > >>> =20 > >>> > >>I'd argue > >> =20 > >> > >>>that > >>>using sip is perfectly fine in those cases. > >>> > >>>If a network for example relies on IPsec, maybe there is no > >>> =20 > >>> > >>need to > >> =20 > >> > >>>use > >>>sips at all. > >>> > >>> =20 > >>> > >>So how would you propose that a user say "I expect you to ship this=20 > >>request and an responses to it over secured links, and if=20 > you can't, I=20 > >>want you to reject it" without using sips:? > >> > >> > >> =20 > >> > >>>I think we need to be pragmatic here. We can not invalidate huge=20 > >>>chunks of RFC 3261 in the way you are proposing. > >>> =20 > >>> > >>I believe otherwise. > >> > >>-- > >>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 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 Thu Oct 26 18:27:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDfQ-0005bj-VK; Thu, 26 Oct 2006 18:25:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDaI-0001cV-D1 for sip@ietf.org; Thu, 26 Oct 2006 18:20:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDYd-0001i6-So for sip@ietf.org; Thu, 26 Oct 2006 18:18:44 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2006 15:18:40 -0700 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 k9QMId1D032393; Thu, 26 Oct 2006 18:18:39 -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 k9QMIdYJ020386; Thu, 26 Oct 2006 18:18:39 -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); Thu, 26 Oct 2006 18:18:39 -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); Thu, 26 Oct 2006 18:18:39 -0400 Message-ID: <4541343D.3080908@cisco.com> Date: Thu, 26 Oct 2006 18:18:37 -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: Rohan Mahy Subject: Re: [Sip] New I-D on UA loose routing References: <452FC0B7.6030007@cisco.com> <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> In-Reply-To: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2006 22:18:39.0179 (UTC) FILETIME=[AFF8D9B0:01C6F94C] DKIM-Signature: a=rsa-sha1; q=dns; l=4992; t=1161901119; x=1162765119; 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]=20New=20I-D=20on=20UA=20loose=20routing |To:Rohan=20Mahy=20; X=v=3Dcisco.com=3B=20h=3DngfVM9O3T0YAsj+sN+YDIIO+vYY=3D; b=kUR8aTq61927t0+YaTW9BlJzBcBY8NK5i0wg5kkJ5LvX8GKD+TBGET+eyfDDZrxE7B2UkaaB sZLjh3DU1RwOs8aEKTuzPmIx+ubRB53X8RC3xmYC9M3bqTyv/h6oYmPV; 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: a7d2e37451f7f22841e3b6f40c67db0f 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 You are equating processing a Route header, with being a proxy. Nothing in RFC 3261 says that if you process a Route header, you are a proxy. Indeed, RFC 3261 is silent on the applicability of Route headers to UA. Certainly I agree we don't want to require a UA to do thigns like mutual TLS. Indeed, I would like to understand what concrete problems you see. Your note points out that there could be other solutions, and then complains that this is making things confusing. Yes, there could be other solutions - I look forward to your draft. I don't think it makes things more confusing. I think this mechanism is quite elegant in that extends the idea of loose routing to UA, and is arguably what we should have done in SIP in the first place. -Jonathan R. Rohan Mahy wrote: > Hi, > > I have read this draft and I think it is a terrible idea in SIP/2.0 to > send a UA an incoming request with a Route header. If we were working > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea > to consider as baseline behavior, but I think this is too major of a > change from the current spec and state of implementation. > > Lets analyze the requirements described in the document. The unkown > gruu, limited-use gruu, subaddressing, and service invocation > requirements can all be met just by restoring the grid parameter to > its rightful place in GRUU. The emergency services requirement is a > tautology; if a proxy wants to rewrite the Request-URI from an SOS > URN, don't do that, insert a loose-route instead; no additional > mechanism or specification is necessary. The freephone requirement > deals with mixed SIP and PSTN networks, where the existing > History-Info (or dare I say Diversion) mechanism is perfectly adequate > and more likely to be implemented in this environment. The alias > requirement can be addresses in a variety of ways including > configuration, or simply restoring the To header to usefulness. My > conclusion is that this mechanism does not solve any requirements we > are not already addressing. (If we were starting from scratch, we > might do things differently). > > As for the implications of handling loose-routing on the UA, I do not > believe the expected behavior is easily containable. The only entities > that should receive requests with additional Route headers are proxy > servers. Embedding a proxy server in/on a UA then requires the UA to > implement TLS, strict route fix ups, loop detection, and a host of > other things. I don't think we want to go there. The alternative is > for us to break the rules and define a "sort of a proxy" role. I > expect picking apart what parts of RFC3261 need to be implemented as a > proxy would be a nightmare. I can also imagine the impact on the > outbound draft if each outbound UA needs to route through an embeded > edge proxy. How will the first "real" edge proxy decide if outbound > processing has been done correctly? > > The concept of logical roles such as proxy, registrar, identity > server, etc. is already confusing to many implementors. If we start > redefining or breaking the rules which describe existing roles, I > believe we are going to have a real mess on our hands. > > thanks, > -rohan > > > > On 10/13/06, Jonathan Rosenberg wrote: > >> I've submitted a new I-D which describes this concept of UA loose >> routing that we've been discussing on the list. This fell out of the >> GRUU discussions as an alternative solution for grid. As the draft >> explains, the mechanism also solves many other problems, like >> sub-addressing, limited use adresses, 8xx number usage, and is even >> required for proper 911/emergency services operation with ecrit. >> >> Until the draft appears in the archives, you can pick it up at: >> http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt >> >> 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 Thu Oct 26 18:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDv7-0005jl-Jp; Thu, 26 Oct 2006 18:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDtr-0004ot-1y for sip@ietf.org; Thu, 26 Oct 2006 18:40:35 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdDjR-0004Qy-74 for sip@ietf.org; Thu, 26 Oct 2006 18:29:50 -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 k9QMTj709755; Thu, 26 Oct 2006 18:29: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] RE: TLS meaning Date: Thu, 26 Oct 2006 17:29:42 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CD29@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5SOmSooX5Pc08Stece7X2zdczIgAAkiowAACP2vA= From: "Samir Srivastava" To: "Francois Audet" , "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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 Fine. I was shot down in the last meeting by Cullen that it is not on the agenda. So I am not in the agreement.=20 Guys voice up, who wants to keep up with the ENGINEERING arguments. BTW it is I ENGINEERING TF. Thx Samir > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Thursday, October 26, 2006 3:09 PM > To: Michael Thomas > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] RE: TLS meaning >=20 > Mike, that's what we agreed NOT to do at the last meeting. > I'm not inventing this: people did not want to deprecate sips. >=20 >=20 >=20 > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Thursday, October 26, 2006 2:51 PM > > To: Audet, Francois (SC100:3055) > > Cc: Dean Willis; IETF SIP List > > Subject: Re: [Sip] RE: TLS meaning > > > > Francois Audet wrote: > > > > >Hi Dean, > > > > > >I'm OK with using other protocols (including DTLS and IPsec) > > to secure > > >signalling, but I don't see why you'd need to use SIPS for that. > > > > > >I'd argue that using SIP for that instead of sips is better. > > Easier to > > >implement. No arcane rules as for SIPS. > > > > > >If this was to be redone, I wouldn't use SIPS at all. I > > believe it was > > >a mistake in the first place. > > > > > >But at the last meeting, we decided it was too late to > > "deprecate it", > > >and I believe we also decided that it would mean what was > > said in RFC > > >3261. We would just clarify the confusion around it. > > > > > > > > It's never too late to deprecate something, especially when > > nobody agrees as to what it means. In fact, given the > > confusion and the general lack of consensus, the mosty > > prudent thing would be *to* excise its use to hopefully force > > the cancer into remission. > > > > I mean, what's the real problem here: > > > > "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a > > SIPS URI any different from a SIP URI" > > > > Doesn't that just about do what you can to cut it out? > > > > Mike > > > > >That doesn't mean that we should INCREASE the role of sips to other > > >protocols like DTLS and IPsec (and whatever). > > > > > >My take is that if you don't use TLS, you wouldn't use SIPS. > > I'd rather > > >we use a Require header for that (for example). > > > > > >And then eventually, we'd outgrow sips entirely. > > > > > >To me, a two step approach like this is (a) backward compatible and > > >doesn't require an overhaul of RFC 3261, and (b) allows to fix the > > >immediate problem of TLS-only SIPS, while giving us more time for a > > >more general solution. > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Dean Willis [mailto:dean.willis@softarmor.com] > > >>Sent: Thursday, October 26, 2006 11:48 AM > > >>To: Audet, Francois (SC100:3055) > > >>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary > > >>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List > > >>Subject: Re: TLS meaning > > >> > > >> > > >>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: > > >> > > >> > > >> > > >>>So, to summarize, you are NOT happy with the current > > consensus, and > > >>>you are proposing something completely different, i.e., > > >>> > > >>> > > >>that instead > > >> > > >> > > >>>of just the current cludgy "last-hop exception rule", we > > also add a > > >>>new "first-hop exception" (and I would imagine a new "any hop > > >>>exception" rule)? > > >>> > > >>> > > >>> > > >>Good summary. > > >> > > >> > > >> > > >> > > >> > > >>>Unlike the current "last hop exception rule" which imposes > > >>> > > >>> > > >>absolutely > > >> > > >> > > >>>no security requirements, your "any hop exception rule" > > >>> > > >>> > > >>would change > > >> > > >> > > >>>this it to a "decent security equivalent to TLS" rule. > > >>> > > >>> > > >>> > > >>Yep. > > >> > > >> > > >> > > >>>This would entail finding all the instances of "TLS" in RFC > > >>> > > >>> > > >>3261 and > > >> > > >> > > >>>make the according changes. > > >>> > > >>> > > >>> > > >>That's one way to approach it. Another way to do it would > > be another > > >>RFC that extends 3261 and says basically "Wherever RFC 321 > > says TLS, > > >>please substitute . . . " > > >> > > >> > > >> > > >>>This is a gigantic change from RFC 2961. I don't think it is > > >>>reasonable. > > >>> > > >>> > > >>> > > >>Doesn't have to be reasonable if it's necessary. > > >> > > >> > > >> > > >>>It is orders of magnitude bigger than what is discussed in > > >>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine > > >>>the meaning of sips, and does NOT invalidate RFC 3261. > > >>> > > >>> > > >>> > > >>Not saying your draft isn't needed. Just saying it isn't enough to > > >>really fix the problem. > > >> > > >> > > >> > > >> > > >>>My take is that using other protocols than TLS is perfectly fine. > > >>>However, > > >>>it does not mean that we should be using sips in that case. > > >>> > > >>> > > >>I'd argue > > >> > > >> > > >>>that > > >>>using sip is perfectly fine in those cases. > > >>> > > >>>If a network for example relies on IPsec, maybe there is no > > >>> > > >>> > > >>need to > > >> > > >> > > >>>use > > >>>sips at all. > > >>> > > >>> > > >>> > > >>So how would you propose that a user say "I expect you to ship this > > >>request and an responses to it over secured links, and if > > you can't, I > > >>want you to reject it" without using sips:? > > >> > > >> > > >> > > >> > > >>>I think we need to be pragmatic here. We can not invalidate huge > > >>>chunks of RFC 3261 in the way you are proposing. > > >>> > > >>> > > >>I believe otherwise. > > >> > > >>-- > > >>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 > > > > > > > > >=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 Oct 26 19:00:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEA6-00045P-2q; Thu, 26 Oct 2006 18:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEA4-000450-K4 for sip@ietf.org; Thu, 26 Oct 2006 18:57:20 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdE4H-0007iL-84 for sip@ietf.org; Thu, 26 Oct 2006 18:51:22 -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 k9QMpI712195; Thu, 26 Oct 2006 18:51:18 -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] Fwd: TLS meaning Date: Thu, 26 Oct 2006 17:51:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCC9EC@zrc2hxm0.corp.nortel.com> In-Reply-To: <86mz7iohip.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Fwd: TLS meaning Thread-Index: Acb5TWdTc9UoUgqcTWKxa8jjMC4q3wAAbr4Q From: "Francois Audet" To: "EKR" , "Samir Srivastava" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 =20 > I don't have a problem with including the information about=20 > what cipher suite was used in headers the same way it is in=20 > RFC822 Received lines. >=20 > I don't, however, agree that you've presented a good argument=20 > that the client's *preferences* should be carried in some header.=20 >=20 > -Ekr Bingo. Fully agree on both points. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 20:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFI3-0004Ni-SN; Thu, 26 Oct 2006 20:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFEf-00032o-VA for sip@ietf.org; Thu, 26 Oct 2006 20:06:09 -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 1GdF2j-00020u-85 for sip@ietf.org; Thu, 26 Oct 2006 19:53:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2006 16:53:48 -0700 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 k9QNrmLf018075; Thu, 26 Oct 2006 16:53:48 -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 k9QNrkW4003754; Thu, 26 Oct 2006 16:53:46 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-306.cisco.com [10.21.153.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9QNfFGd026021; Thu, 26 Oct 2006 16:41:15 -0700 Message-ID: <45414A8E.1080704@cisco.com> Date: Thu, 26 Oct 2006 16:53:50 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; 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=6726; t=1161906828; x=1162770828; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=rxyLHnJ5S5tNDzuPM+uBVpdsn69Fy+fcGWxbQGvfy8OtSuWxSMa2pHrsSRUSblTVP8az5aOo MCQjsBFfzeiuH/aA0ZQKSYKWY4WbocWNu6hCtseCAeUHlH9bQzkBdgtr; X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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 Francois Audet wrote: >Mike, that's what we agreed NOT to do at the last meeting. >I'm not inventing this: people did not want to deprecate sips. > > That's nice. Meetings are not definitive, the list is. Until the chairs tell us that this is closed, the consensus at the meeting is not binding. Mike > > > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Thursday, October 26, 2006 2:51 PM >>To: Audet, Francois (SC100:3055) >>Cc: Dean Willis; IETF SIP List >>Subject: Re: [Sip] RE: TLS meaning >> >>Francois Audet wrote: >> >> >> >>>Hi Dean, >>> >>>I'm OK with using other protocols (including DTLS and IPsec) >>> >>> >>to secure >> >> >>>signalling, but I don't see why you'd need to use SIPS for that. >>> >>>I'd argue that using SIP for that instead of sips is better. >>> >>> >>Easier to >> >> >>>implement. No arcane rules as for SIPS. >>> >>>If this was to be redone, I wouldn't use SIPS at all. I >>> >>> >>believe it was >> >> >>>a mistake in the first place. >>> >>>But at the last meeting, we decided it was too late to >>> >>> >>"deprecate it", >> >> >>>and I believe we also decided that it would mean what was >>> >>> >>said in RFC >> >> >>>3261. We would just clarify the confusion around it. >>> >>> >>> >>> >>It's never too late to deprecate something, especially when >>nobody agrees as to what it means. In fact, given the >>confusion and the general lack of consensus, the mosty >>prudent thing would be *to* excise its use to hopefully force >>the cancer into remission. >> >>I mean, what's the real problem here: >> >> "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a >> SIPS URI any different from a SIP URI" >> >>Doesn't that just about do what you can to cut it out? >> >> Mike >> >> >> >>>That doesn't mean that we should INCREASE the role of sips to other >>>protocols like DTLS and IPsec (and whatever). >>> >>>My take is that if you don't use TLS, you wouldn't use SIPS. >>> >>> >>I'd rather >> >> >>>we use a Require header for that (for example). >>> >>>And then eventually, we'd outgrow sips entirely. >>> >>>To me, a two step approach like this is (a) backward compatible and >>>doesn't require an overhaul of RFC 3261, and (b) allows to fix the >>>immediate problem of TLS-only SIPS, while giving us more time for a >>>more general solution. >>> >>> >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Dean Willis [mailto:dean.willis@softarmor.com] >>>>Sent: Thursday, October 26, 2006 11:48 AM >>>>To: Audet, Francois (SC100:3055) >>>>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary >>>>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List >>>>Subject: Re: TLS meaning >>>> >>>> >>>>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: >>>> >>>> >>>> >>>> >>>> >>>>>So, to summarize, you are NOT happy with the current >>>>> >>>>> >>consensus, and >> >> >>>>>you are proposing something completely different, i.e., >>>>> >>>>> >>>>> >>>>> >>>>that instead >>>> >>>> >>>> >>>> >>>>>of just the current cludgy "last-hop exception rule", we >>>>> >>>>> >>also add a >> >> >>>>>new "first-hop exception" (and I would imagine a new "any hop >>>>>exception" rule)? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Good summary. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Unlike the current "last hop exception rule" which imposes >>>>> >>>>> >>>>> >>>>> >>>>absolutely >>>> >>>> >>>> >>>> >>>>>no security requirements, your "any hop exception rule" >>>>> >>>>> >>>>> >>>>> >>>>would change >>>> >>>> >>>> >>>> >>>>>this it to a "decent security equivalent to TLS" rule. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Yep. >>>> >>>> >>>> >>>> >>>> >>>>>This would entail finding all the instances of "TLS" in RFC >>>>> >>>>> >>>>> >>>>> >>>>3261 and >>>> >>>> >>>> >>>> >>>>>make the according changes. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>That's one way to approach it. Another way to do it would >>>> >>>> >>be another >> >> >>>>RFC that extends 3261 and says basically "Wherever RFC 321 >>>> >>>> >>says TLS, >> >> >>>>please substitute . . . " >>>> >>>> >>>> >>>> >>>> >>>>>This is a gigantic change from RFC 2961. I don't think it is >>>>>reasonable. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Doesn't have to be reasonable if it's necessary. >>>> >>>> >>>> >>>> >>>> >>>>>It is orders of magnitude bigger than what is discussed in >>>>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine >>>>>the meaning of sips, and does NOT invalidate RFC 3261. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Not saying your draft isn't needed. Just saying it isn't enough to >>>>really fix the problem. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>My take is that using other protocols than TLS is perfectly fine. >>>>>However, >>>>>it does not mean that we should be using sips in that case. >>>>> >>>>> >>>>> >>>>> >>>>I'd argue >>>> >>>> >>>> >>>> >>>>>that >>>>>using sip is perfectly fine in those cases. >>>>> >>>>>If a network for example relies on IPsec, maybe there is no >>>>> >>>>> >>>>> >>>>> >>>>need to >>>> >>>> >>>> >>>> >>>>>use >>>>>sips at all. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>So how would you propose that a user say "I expect you to ship this >>>>request and an responses to it over secured links, and if >>>> >>>> >>you can't, I >> >> >>>>want you to reject it" without using sips:? >>>> >>>> >>>> >>>> >>>> >>>> >>>>>I think we need to be pragmatic here. We can not invalidate huge >>>>>chunks of RFC 3261 in the way you are proposing. >>>>> >>>>> >>>>> >>>>> >>>>I believe otherwise. >>>> >>>>-- >>>>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 Oct 26 20:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFQ8-0001Df-Ow; Thu, 26 Oct 2006 20:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFQ7-0001DU-BF for sip@ietf.org; Thu, 26 Oct 2006 20:17:59 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFQ5-0007Kv-2p for sip@ietf.org; Thu, 26 Oct 2006 20:17:59 -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 k9R0Hql10359; Thu, 26 Oct 2006 20:17: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] RE: TLS meaning Date: Thu, 26 Oct 2006 19:17:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> In-Reply-To: <45414A8E.1080704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5Wf7UbxTSe6MZRpGfG+zyKXQrNgAAakcQ From: "Francois Audet" To: "Michael Thomas" , "ext Cullen Jennings" , "Peterson, Jon" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Well, go ahead: propose to deprecate SIPS then. (I think it was me who brought it up in Montreal by the way). The official meeting minutes said (in bold): We have consensus that we will not deprecate SIPS. I'd like to get some advice from the ADs (again). I don't find it particularly productive to have random proposals from the list derail the concensus that we have painfully established. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Thursday, October 26, 2006 4:54 PM > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >Mike, that's what we agreed NOT to do at the last meeting. > >I'm not inventing this: people did not want to deprecate sips.=20 > > =20 > > >=20 > That's nice. Meetings are not definitive, the list is. Until=20 > the chairs tell us that this is closed, the consensus at the=20 > meeting is not binding. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 26 20:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFQl-0001nb-4L; Thu, 26 Oct 2006 20:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFQj-0001j0-ET for sip@ietf.org; Thu, 26 Oct 2006 20:18:37 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFQh-0007TR-Vl for sip@ietf.org; Thu, 26 Oct 2006 20:18: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 k9R0IWI05116; Thu, 26 Oct 2006 20:18: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] RE: TLS meaning Date: Thu, 26 Oct 2006 19:18:31 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F43CDEB@zrc2hxm2.corp.nortel.com> In-Reply-To: <45414A8E.1080704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb5XJKq8bofr68GRnqiuEdwDXHPJgAAEKVw From: "Samir Srivastava" To: "Michael Thomas" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 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 Agreed. I too believe in democracy with *WELL INFORMED* voting/hum. Also I request the guys voting/huming to keep SIPS to let me know the reasons, if they want to. Thx Samir > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, October 26, 2006 4:54 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List; Dean Willis > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >Mike, that's what we agreed NOT to do at the last meeting. > >I'm not inventing this: people did not want to deprecate sips. > > > > >=20 > That's nice. Meetings are not definitive, the list is. Until the chairs > tell us that > this is closed, the consensus at the meeting is not binding. >=20 > Mike >=20 > > > > > > > > > >>-----Original Message----- > >>From: Michael Thomas [mailto:mat@cisco.com] > >>Sent: Thursday, October 26, 2006 2:51 PM > >>To: Audet, Francois (SC100:3055) > >>Cc: Dean Willis; IETF SIP List > >>Subject: Re: [Sip] RE: TLS meaning > >> > >>Francois Audet wrote: > >> > >> > >> > >>>Hi Dean, > >>> > >>>I'm OK with using other protocols (including DTLS and IPsec) > >>> > >>> > >>to secure > >> > >> > >>>signalling, but I don't see why you'd need to use SIPS for that. > >>> > >>>I'd argue that using SIP for that instead of sips is better. > >>> > >>> > >>Easier to > >> > >> > >>>implement. No arcane rules as for SIPS. > >>> > >>>If this was to be redone, I wouldn't use SIPS at all. I > >>> > >>> > >>believe it was > >> > >> > >>>a mistake in the first place. > >>> > >>>But at the last meeting, we decided it was too late to > >>> > >>> > >>"deprecate it", > >> > >> > >>>and I believe we also decided that it would mean what was > >>> > >>> > >>said in RFC > >> > >> > >>>3261. We would just clarify the confusion around it. > >>> > >>> > >>> > >>> > >>It's never too late to deprecate something, especially when > >>nobody agrees as to what it means. In fact, given the > >>confusion and the general lack of consensus, the mosty > >>prudent thing would be *to* excise its use to hopefully force > >>the cancer into remission. > >> > >>I mean, what's the real problem here: > >> > >> "A sender MUST NOT send a SIPS URI, and a receiver MUST NOT treat a > >> SIPS URI any different from a SIP URI" > >> > >>Doesn't that just about do what you can to cut it out? > >> > >> Mike > >> > >> > >> > >>>That doesn't mean that we should INCREASE the role of sips to other > >>>protocols like DTLS and IPsec (and whatever). > >>> > >>>My take is that if you don't use TLS, you wouldn't use SIPS. > >>> > >>> > >>I'd rather > >> > >> > >>>we use a Require header for that (for example). > >>> > >>>And then eventually, we'd outgrow sips entirely. > >>> > >>>To me, a two step approach like this is (a) backward compatible and > >>>doesn't require an overhaul of RFC 3261, and (b) allows to fix the > >>>immediate problem of TLS-only SIPS, while giving us more time for a > >>>more general solution. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Dean Willis [mailto:dean.willis@softarmor.com] > >>>>Sent: Thursday, October 26, 2006 11:48 AM > >>>>To: Audet, Francois (SC100:3055) > >>>>Cc: Adam Roach; Paul Kyzivat; Robert Sparks; Barnes, Mary > >>>>(RICH2:AR00); Gonzalo Camarillo; IETF SIP List > >>>>Subject: Re: TLS meaning > >>>> > >>>> > >>>>On Oct 25, 2006, at 2:08 PM, Francois Audet wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>So, to summarize, you are NOT happy with the current > >>>>> > >>>>> > >>consensus, and > >> > >> > >>>>>you are proposing something completely different, i.e., > >>>>> > >>>>> > >>>>> > >>>>> > >>>>that instead > >>>> > >>>> > >>>> > >>>> > >>>>>of just the current cludgy "last-hop exception rule", we > >>>>> > >>>>> > >>also add a > >> > >> > >>>>>new "first-hop exception" (and I would imagine a new "any hop > >>>>>exception" rule)? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Good summary. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Unlike the current "last hop exception rule" which imposes > >>>>> > >>>>> > >>>>> > >>>>> > >>>>absolutely > >>>> > >>>> > >>>> > >>>> > >>>>>no security requirements, your "any hop exception rule" > >>>>> > >>>>> > >>>>> > >>>>> > >>>>would change > >>>> > >>>> > >>>> > >>>> > >>>>>this it to a "decent security equivalent to TLS" rule. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Yep. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>This would entail finding all the instances of "TLS" in RFC > >>>>> > >>>>> > >>>>> > >>>>> > >>>>3261 and > >>>> > >>>> > >>>> > >>>> > >>>>>make the according changes. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>That's one way to approach it. Another way to do it would > >>>> > >>>> > >>be another > >> > >> > >>>>RFC that extends 3261 and says basically "Wherever RFC 321 > >>>> > >>>> > >>says TLS, > >> > >> > >>>>please substitute . . . " > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>This is a gigantic change from RFC 2961. I don't think it is > >>>>>reasonable. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Doesn't have to be reasonable if it's necessary. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>It is orders of magnitude bigger than what is discussed in > >>>>>draft-audet-sip-sips-guidelines which does NOT attempt to redefine > >>>>>the meaning of sips, and does NOT invalidate RFC 3261. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Not saying your draft isn't needed. Just saying it isn't enough to > >>>>really fix the problem. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>My take is that using other protocols than TLS is perfectly fine. > >>>>>However, > >>>>>it does not mean that we should be using sips in that case. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I'd argue > >>>> > >>>> > >>>> > >>>> > >>>>>that > >>>>>using sip is perfectly fine in those cases. > >>>>> > >>>>>If a network for example relies on IPsec, maybe there is no > >>>>> > >>>>> > >>>>> > >>>>> > >>>>need to > >>>> > >>>> > >>>> > >>>> > >>>>>use > >>>>>sips at all. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>So how would you propose that a user say "I expect you to ship this > >>>>request and an responses to it over secured links, and if > >>>> > >>>> > >>you can't, I > >> > >> > >>>>want you to reject it" without using sips:? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I think we need to be pragmatic here. We can not invalidate huge > >>>>>chunks of RFC 3261 in the way you are proposing. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>I believe otherwise. > >>>> > >>>>-- > >>>>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 > >>> > >>> > >>> > >>> >=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 Oct 26 20:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFo1-0005EP-KG; Thu, 26 Oct 2006 20:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFhh-0002ud-SS for sip@ietf.org; Thu, 26 Oct 2006 20:36:09 -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 1GdFZ6-0000gV-8F for sip@ietf.org; Thu, 26 Oct 2006 20:27:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2006 17:27:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9R0RFPv029861; Thu, 26 Oct 2006 17:27:15 -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 k9R0RFW4000169; Thu, 26 Oct 2006 17:27:15 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-306.cisco.com [10.21.153.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9R0EiwT026753; Thu, 26 Oct 2006 17:14:44 -0700 Message-ID: <45415267.7000905@cisco.com> Date: Thu, 26 Oct 2006 17:27:19 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1633; t=1161908835; x=1162772835; c=relaxed/simple; s=sjdkim1002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=KbO6L2tE2y1aExJItEhLzswsg5Ya9vFfcmiDDhbMdCxHKpgeAOhdJW/6aKXxxp5/6mKsUY+d H1jp1YoIX90OTbKkj8CbalmM3yl4lXULedWnfDAh5pMhjOXhG1SuQIL+; X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ext Cullen Jennings , IETF SIP List , "Peterson, Jon" , 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 Francois Audet wrote: >Well, go ahead: propose to deprecate SIPS then. (I think it was me >who brought it up in Montreal by the way). > > Sure. Deprecate SIPS. It's always been a bad idea. The fact that 5 or so years out nobody still agrees what if anything it means is a very strong argument that it's a dead letter. >The official meeting minutes said (in bold): > > We have consensus that we will not deprecate SIPS. > >I'd like to get some advice from the ADs (again). > >I don't find it particularly productive to have random >proposals from the list derail the concensus that we have >painfully established. > > Well, I don't think I've been in any way "random" here since I've been saying that this was a bad idea for going on 5 years now. Nor do I find Dean's reservations particularly random either. But what I will say is that the list is where the consensus is gauged, not the meeting. Were I at the meeting, it would have seemed a lot less consensusful. Mike > > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Thursday, October 26, 2006 4:54 PM >>To: Audet, Francois (SC100:3055) >>Cc: Dean Willis; IETF SIP List >>Subject: Re: [Sip] RE: TLS meaning >> >>Francois Audet wrote: >> >> >> >>>Mike, that's what we agreed NOT to do at the last meeting. >>>I'm not inventing this: people did not want to deprecate sips. >>> >>> >>> >>> >>That's nice. Meetings are not definitive, the list is. Until >>the chairs tell us that this is closed, the consensus at the >>meeting is not binding. >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL76-0002SZ-FU; Fri, 27 Oct 2006 02:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL75-0002S7-Jn for sip@ietf.org; Fri, 27 Oct 2006 02:22:43 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKyt-0001we-FB for sip@ietf.org; Fri, 27 Oct 2006 02:14:16 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 344E2AC422; Fri, 27 Oct 2006 09:14:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.41905.89752.414931@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:14:09 +0300 To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <45412DD8.4090207@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> <45412DD8.4090207@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , Francois Audet , 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 Michael Thomas writes: > >If this was to be redone, I wouldn't use SIPS at all. I believe it was a > >mistake in the first place. yes, SIPS was a big mistake in the first place. SIPS was rushed into RFC3261 drafts at the very last moment without any kind of implementation nor even emailing list experience. now it is high time to admit that it was a big mistake. my understanding is that rfc3261 is just a PROPOSED standard, which very well can and should be changed to correct the SIPS mistake. > It's never too late to deprecate something, especially when nobody agrees as > to what it means. yes, as i have proposed earlier, lets deprecate SIPS and introduce something else later when we know what it should be and have positive implementation experience. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6x-0002Ow-EP; Fri, 27 Oct 2006 02:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6v-0002HK-Fk for sip@ietf.org; Fri, 27 Oct 2006 02:22:33 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL2S-0002Xc-L5 for sip@ietf.org; Fri, 27 Oct 2006 02:17:58 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id EF4E5AC422; Fri, 27 Oct 2006 09:17:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42131.920747.635525@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:17:55 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> References: <45412DD8.4090207@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-SigFrom sip-bounces@ietf.org Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL76-0002SZ-FU; Fri, 27 Oct 2006 02:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL75-0002S7-Jn for sip@ietf.org; Fri, 27 Oct 2006 02:22:43 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKyt-0001we-FB for sip@ietf.org; Fri, 27 Oct 2006 02:14:16 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 344E2AC422; Fri, 27 Oct 2006 09:14:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.41905.89752.414931@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:14:09 +0300 To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <45412DD8.4090207@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> <45412DD8.4090207@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , Francois Audet , 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 Michael Thomas writes: > >If this was to be redone, I wouldn't use SIPS at all. I believe it was a > >mistake in the first place. yes, SIPS was a big mistake in the first place. SIPS was rushed into RFC3261 drafts at the very last moment without any kind of implementation nor even emailing list experience. now it is high time to admit that it was a big mistake. my understanding is that rfc3261 is just a PROPOSED standard, which very well can and should be changed to correct the SIPS mistake. > It's never too late to deprecate something, especially when nobody agrees as > to what it means. yes, as i have proposed earlier, lets deprecate SIPS and introduce something else later when we know what it should be and have positive implementation experience. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6x-0002Ow-EP; Fri, 27 Oct 2006 02:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6v-0002HK-Fk for sip@ietf.org; Fri, 27 Oct 2006 02:22:33 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL2S-0002Xc-L5 for sip@ietf.org; Fri, 27 Oct 2006 02:17:58 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id EF4E5AC422; Fri, 27 Oct 2006 09:17:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42131.920747.635525@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:17:55 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> References: <45412DD8.4090207@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , Michael Thomas , 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 Francois Audet writes: > Mike, that's what we agreed NOT to do at the last meeting. > I'm not inventing this: people did not want to deprecate sips. in the early days ietf did its decisions on the mailing lists. not everybody can afford to attend the meetings. my customers pay for working code, not me sitting in meetings. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6p-0002Jc-RR; Fri, 27 Oct 2006 02:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6k-0002Fs-FX for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL6j-0003G4-1g for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 5CBADAC422; Fri, 27 Oct 2006 09:22:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42396.322245.232942@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:22:20 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> References: <45414A8E.1080704@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ext Cullen Jennings , IETF SIP List , Michael Thomas , "Peterson, Jon" , 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 Francois Audet writes: > I don't find it particularly productive to have random > proposals from the list derail the concensus that we have > painfully established. your term "random proposal" is quite insulting. is it so that only proposals from nortel, cisco, etc big companies are not "random". -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL76-0002SZ-FU; Fri, 27 Oct 2006 02:22:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL75-0002S7-Jn for sip@ietf.org; Fri, 27 Oct 2006 02:22:43 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdKyt-0001we-FB for sip@ietf.org; Fri, 27 Oct 2006 02:14:16 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 344E2AC422; Fri, 27 Oct 2006 09:14:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.41905.89752.414931@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:14:09 +0300 To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <45412DD8.4090207@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> <45412DD8.4090207@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , Francois Audet , 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 Michael Thomas writes: > >If this was to be redone, I wouldn't use SIPS at all. I believe it was a > >mistake in the first place. yes, SIPS was a big mistake in the first place. SIPS was rushed into RFC3261 drafts at the very last moment without any kind of implementation nor even emailing list experience. now it is high time to admit that it was a big mistake. my understanding is that rfc3261 is just a PROPOSED standard, which very well can and should be changed to correct the SIPS mistake. > It's never too late to deprecate something, especially when nobody agrees as > to what it means. yes, as i have proposed earlier, lets deprecate SIPS and introduce something else later when we know what it should be and have positive implementation experience. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6x-0002Ow-EP; Fri, 27 Oct 2006 02:22:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6v-0002HK-Fk for sip@ietf.org; Fri, 27 Oct 2006 02:22:33 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL2S-0002Xc-L5 for sip@ietf.org; Fri, 27 Oct 2006 02:17:58 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id EF4E5AC422; Fri, 27 Oct 2006 09:17:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42131.920747.635525@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:17:55 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> References: <45412DD8.4090207@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCC958@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , Michael Thomas , 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 Francois Audet writes: > Mike, that's what we agreed NOT to do at the last meeting. > I'm not inventing this: people did not want to deprecate sips. in the early days ietf did its decisions on the mailing lists. not everybody can afford to attend the meetings. my customers pay for working code, not me sitting in meetings. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6p-0002Jc-RR; Fri, 27 Oct 2006 02:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6k-0002Fs-FX for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL6j-0003G4-1g for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 5CBADAC422; Fri, 27 Oct 2006 09:22:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42396.322245.232942@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:22:20 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> References: <45414A8E.1080704@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ext Cullen Jennings , IETF SIP List , Michael Thomas , "Peterson, Jon" , 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 Francois Audet writes: > I don't find it particularly productive to have random > proposals from the list derail the concensus that we have > painfully established. your term "random proposal" is quite insulting. is it so that only proposals from nortel, cisco, etc big companies are not "random". -- 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 nature: 7bac9cb154eb5790ae3b2913587a40de Cc: IETF SIP List , Michael Thomas , 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 Francois Audet writes: > Mike, that's what we agreed NOT to do at the last meeting. > I'm not inventing this: people did not want to deprecate sips. in the early days ietf did its decisions on the mailing lists. not everybody can afford to attend the meetings. my customers pay for working code, not me sitting in meetings. -- 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 Fri Oct 27 02:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6p-0002Jc-RR; Fri, 27 Oct 2006 02:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6k-0002Fs-FX for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL6j-0003G4-1g for sip@ietf.org; Fri, 27 Oct 2006 02:22:22 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 5CBADAC422; Fri, 27 Oct 2006 09:22:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17729.42396.322245.232942@harjus.tutpro.com> Date: Fri, 27 Oct 2006 09:22:20 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> References: <45414A8E.1080704@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DBCCA7A@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ext Cullen Jennings , IETF SIP List , Michael Thomas , "Peterson, Jon" , 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 Francois Audet writes: > I don't find it particularly productive to have random > proposals from the list derail the concensus that we have > painfully established. your term "random proposal" is quite insulting. is it so that only proposals from nortel, cisco, etc big companies are not "random". -- 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 Fri Oct 27 08:40:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQxU-00031o-8Y; Fri, 27 Oct 2006 08:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQxT-0002yu-1M for sip@ietf.org; Fri, 27 Oct 2006 08:37:11 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdQxQ-00050f-MF for sip@ietf.org; Fri, 27 Oct 2006 08:37:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdQx8-0005Y0-Ux; Fri, 27 Oct 2006 07:36:51 -0500 From: "Brian Rosen" To: "'Michael Thomas'" , "'Francois Audet'" Subject: RE: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 08:36:51 -0400 Message-ID: <063801c6f9c4$9630e1d0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb5YRZsRjs1pySyQQq9DEYkkZXFmAAYpdHg In-Reply-To: <45415267.7000905@cisco.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 - [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: 73734d43604d52d23b3eba644a169745 Cc: 'ext Cullen Jennings' , 'IETF SIP List' , "Peterson, Jon" , '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 Okay, I'll take the bait. I think the problem with sips was the exception for last hop. Get rid of that and sips means the UA requests end to end TLS and as far as we know, he got it. It's hop by hop, which means a transitive trust model, and therefore subject to an untrustworthy proxy screwing up. Even with such limitations, I think that is valuable. Needs some clarifications as has been discussed. There may be other valuable security mechanisms to be proposed, but TLS end to end is useful. I am NOT in favor of deprecating sips. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, October 26, 2006 8:27 PM > To: Francois Audet > Cc: ext Cullen Jennings; IETF SIP List; Peterson, Jon; Dean Willis > Subject: Re: [Sip] RE: TLS meaning > > Francois Audet wrote: > > >Well, go ahead: propose to deprecate SIPS then. (I think it was me > >who brought it up in Montreal by the way). > > > > > > Sure. Deprecate SIPS. It's always been a bad idea. The fact that > 5 or so years out nobody still agrees what if anything it means is > a very strong argument that it's a dead letter. > > >The official meeting minutes said (in bold): > > > > We have consensus that we will not deprecate SIPS. > > > >I'd like to get some advice from the ADs (again). > > > >I don't find it particularly productive to have random > >proposals from the list derail the concensus that we have > >painfully established. > > > > > > Well, I don't think I've been in any way "random" here since I've been > saying > that this was a bad idea for going on 5 years now. Nor do I find Dean's > reservations particularly random either. But what I will say is that > the list is where the consensus is gauged, not the meeting. Were I at the > meeting, it would have seemed a lot less consensusful. > > Mike > > > > > > > > >>-----Original Message----- > >>From: Michael Thomas [mailto:mat@cisco.com] > >>Sent: Thursday, October 26, 2006 4:54 PM > >>To: Audet, Francois (SC100:3055) > >>Cc: Dean Willis; IETF SIP List > >>Subject: Re: [Sip] RE: TLS meaning > >> > >>Francois Audet wrote: > >> > >> > >> > >>>Mike, that's what we agreed NOT to do at the last meeting. > >>>I'm not inventing this: people did not want to deprecate sips. > >>> > >>> > >>> > >>> > >>That's nice. Meetings are not definitive, the list is. Until > >>the chairs tell us that this is closed, the consensus at the > >>meeting is not binding. > >> > >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 27 09:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRkz-00010B-CF; Fri, 27 Oct 2006 09:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRky-000106-EK for sip@ietf.org; Fri, 27 Oct 2006 09:28:20 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdJcA-0004aG-4i for sip@ietf.org; Fri, 27 Oct 2006 00:46:43 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9R47C314862; Thu, 26 Oct 2006 22:07:12 -0600 Message-ID: <454185E7.1000605@ntt-at.com> Date: Thu, 26 Oct 2006 21:07:03 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] New I-D on UA loose routing References: <452FC0B7.6030007@cisco.com> In-Reply-To: <452FC0B7.6030007@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Interesting draft... I generally like the idea although having a spec such as p-called-party-id already may raise an argument about some of the motives behind this draft(Yes I know, p-header is for restricted environment and I know we don't want to define too many vehicles to carry an identities...). Anyhow, I don't know how well this is going to work for Service URN(911/emergency). AFAIK idea behind putting the service URN in either To or R-URI is not to address a specific AoR or name but it is to mark a call so intermediaries can prioritize the call and treat it as an emergency call. And because it does not address a target, call may be retargeted before it gets to any ESC and may lose the marker(Service URN). I guess we can probably write something in phonebcp to prevent this but it is something to keep in mind. Regards Shida Jonathan Rosenberg wrote: > I've submitted a new I-D which describes this concept of UA loose > routing that we've been discussing on the list. This fell out of the > GRUU discussions as an alternative solution for grid. As the draft > explains, the mechanism also solves many other problems, like > sub-addressing, limited use adresses, 8xx number usage, and is even > required for proper 911/emergency services operation with ecrit. > > Until the draft appears in the archives, you can pick it up at: > http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt > > Thanks, > 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 Fri Oct 27 09:54:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdS82-0000Yf-Cd; Fri, 27 Oct 2006 09:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdS80-0000Uz-IH for sip@ietf.org; Fri, 27 Oct 2006 09:52:08 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdS7w-0006Rh-6F for sip@ietf.org; Fri, 27 Oct 2006 09:52:08 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 458301E8C28; Fri, 27 Oct 2006 06:52:03 -0700 (PDT) To: "Brian Rosen" Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 06:52:03 -0700 In-Reply-To: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> (Brian Rosen's message of "Fri, 27 Oct 2006 08:36:51 -0400") Message-ID: <8664e5ooho.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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'ext Cullen Jennings' , 'Michael Thomas' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 "Brian Rosen" writes: > Okay, I'll take the bait. > > I think the problem with sips was the exception for last hop. Get rid of > that and sips means the UA requests end to end TLS and as far as we know, he > got it. It's hop by hop, which means a transitive trust model, and > therefore subject to an untrustworthy proxy screwing up. Even with such > limitations, I think that is valuable. Needs some clarifications as has > been discussed. > > There may be other valuable security mechanisms to be proposed, but TLS end > to end is useful. > > I am NOT in favor of deprecating sips. I basically agree with Brian here. In the previous contexts where SSL has been deployed, one of two things is usually done: - The reference which the client dereferences explicitly asserts that TLS is to be used (e.g., HTTPS) - The client and server mutually discover that they are to use TLS (e.g., STARTTLS for SMTP). SIPS attempts to import the first model into SIP, but because SIP, unlike HTTP, doesn't have a direct connection from the client to the server, it needs to have the proxies transitively enforce the same security conditions (use TLS) that the client enforces. As Brian says, this is transitive trust, but it's what we've got. At the time it was accepted, the last-hop exception seemed sensible (by analogy to the last-hop HTTPS accelerators used in many data centers), but as we've seen that produces problems and the need for it can be removed with outbound. I haven't seen any arguments I find convincing that that's not the way to go. -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 Oct 27 10:07:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdSKK-0000kA-5v; Fri, 27 Oct 2006 10:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcuFI-0004zR-PL for sip@ietf.org; Wed, 25 Oct 2006 21:41:24 -0400 Received: from mail2.zte.com.cn ([202.103.147.144] helo=Riskfilter2.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcuFD-0007wU-N0 for sip@ietf.org; Wed, 25 Oct 2006 21:41:23 -0400 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 83345.1112621526; Thu, 26 Oct 2006 10:04:49 +0800 (CST) To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: zhang.lu2@zte.com.cn Date: Thu, 26 Oct 2006 09:40:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2006-10-26 09:40:51, Serialize complete at 2006-10-26 09:40:51 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c X-Mailman-Approved-At: Fri, 27 Oct 2006 10:04:50 -0400 Subject: [Sip] Help: About Early-Session and Session X-BeenThere: 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="===============1373757933==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1373757933== Content-Type: multipart/alternative; boundary="=_alternative 000935E948257213_=" This is a multipart message in MIME format. --=_alternative 000935E948257213_= Content-Type: text/plain; charset="US-ASCII" Dear Sip Group, There encounters a question when I read RFC 3959 and RFC 3960 which refer to the Early-Session , that is "Does Offer/Answer Model defined in RFC 3264 apply to Early-Session and Session independently?" In RFC 3959 section 7, there is a example as below: A B | | |--------(1) INVITE-------->| | offer | | | |<--(2) Session Progress----| | early-offer | | answer | | | |---------(3) PRACK-------->| | early-answer | | | |<--------(4) 200 OK--------| | | | * * | | ************************* | |* Early Media *| | ************************* | | * * | | | |<--------(5) 200 OK--------| | | |----------(6) ACK--------->| | | Figure 1: Message flow Hope to have a letter from you soon. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000935E948257213_= Content-Type: text/html; charset="US-ASCII"
Dear Sip Group,

     There encounters a question when I read RFC 3959 and RFC 3960 which refer to the Early-Session , that is
   
       "Does Offer/Answer Model defined in RFC 3264 apply to Early-Session and Session independently?"

     In RFC 3959 section 7, there is a example as below:
      A                           B
      |                           |
      |--------(1) INVITE-------->|
      |            offer          |
      |                           |
      |<--(2) Session Progress----|
      |       early-offer         |
      |       answer              |
      |                           |
      |---------(3) PRACK-------->|
      |             early-answer  |
      |                           |
      |<--------(4) 200 OK--------|
      |                           |
      |  *                     *  |
      | ************************* |
      |*       Early Media       *|
      | ************************* |
      |  *                     *  |
      |                           |
      |<--------(5) 200 OK--------|
      |                           |
      |----------(6) ACK--------->|
      |                           |

          Figure 1: Message flow
         

    Hope to have a letter from you soon.

     
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000935E948257213_=-- --===============1373757933== 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 --===============1373757933==-- From sip-bounces@ietf.org Fri Oct 27 11:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTXd-0008EN-JW; Fri, 27 Oct 2006 11:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTXc-0008EI-96 for sip@ietf.org; Fri, 27 Oct 2006 11:22:40 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTXX-0004Ug-SX for sip@ietf.org; Fri, 27 Oct 2006 11:22:40 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 080B8AC422; Fri, 27 Oct 2006 18:22:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17730.9269.969078.267012@harjus.tutpro.com> Date: Fri, 27 Oct 2006 18:22:29 +0300 To: EKR Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <8664e5ooho.fsf@raman.networkresonance.com> References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <8664e5ooho.fsf@raman.networkresonance.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'ext Cullen Jennings' , 'Michael Thomas' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Eric Rescorla writes: > At the time it was accepted, the last-hop exception seemed sensible > (by analogy to the last-hop HTTPS accelerators used in many > data centers), but as we've seen that produces problems and > the need for it can be removed with outbound. I haven't > seen any arguments I find convincing that that's not the way > to go. there was lots of opposition when someone (i think jonathan) proposed that SIPS means tls on every hop, i.e., if the route through proxies cannot implement it, then the request must fail. i personally would have been happy with this interpretation. -- 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 Fri Oct 27 11:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTmJ-0004lH-HN; Fri, 27 Oct 2006 11:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTmI-0004l8-2f for sip@ietf.org; Fri, 27 Oct 2006 11:37:50 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTmD-000735-Mq for sip@ietf.org; Fri, 27 Oct 2006 11:37:50 -0400 Received: from [209.172.111.2] (helo=JMHLap3.stevecrocker.com) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GdTmC-0000uJ-LX for sip@ietf.org; Fri, 27 Oct 2006 11:37:45 -0400 Message-Id: <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 27 Oct 2006 11:37:37 -0400 To: 'IETF SIP List' From: "Joel M. Halpern" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120ac5bf900ac6cce4ddcb4f70853d54929c9b5e52464f59f68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.172.111.2 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 So let me ask a question. Maybe a stupid question. You are sending a SIP invite to someone. You want it secured. Let's suppose you want it secured end to end. Let's even suppose that if it is not secured end to end you want it ti fail. So you specify SIPS in accordance with your definition. Do you really want that call to fail because two of the proxies in the path are using IPSec instead of TLS? Yours, Joel M. Halpern At 08:36 AM 10/27/2006, Brian Rosen wrote: >Okay, I'll take the bait. > >I think the problem with sips was the exception for last hop. Get rid of >that and sips means the UA requests end to end TLS and as far as we know, he >got it. It's hop by hop, which means a transitive trust model, and >therefore subject to an untrustworthy proxy screwing up. Even with such >limitations, I think that is valuable. Needs some clarifications as has >been discussed. > >There may be other valuable security mechanisms to be proposed, but TLS end >to end is useful. > >I am NOT in favor of deprecating sips. > >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 Fri Oct 27 11:41:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTo3-0007HW-P9; Fri, 27 Oct 2006 11:39:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTo2-0007HP-AY for sip@ietf.org; Fri, 27 Oct 2006 11:39:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTny-0007L2-FB for sip@ietf.org; Fri, 27 Oct 2006 11:39:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 08:39:34 -0700 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 k9RFdXJK002625; Fri, 27 Oct 2006 08:39:33 -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 k9RFdXW4019762; Fri, 27 Oct 2006 08:39:33 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-306.cisco.com [10.21.153.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RFQqMS014607; Fri, 27 Oct 2006 08:26:54 -0700 Message-ID: <45422830.4040700@cisco.com> Date: Fri, 27 Oct 2006 08:39:28 -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: Brian Rosen Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> In-Reply-To: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1237; t=1161963573; x=1162827573; c=relaxed/simple; s=sjdkim3002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=RR9AdJKmJo0pK0DarJLrCFEkSq6Gr1iv2HJz5YcXeuNvvwFBsXTH9ZtS+dABSIjLhhXss3HZ i5r95yBo2M6JIrj2iuaLLfjz6DJMGCAzNrsbbnOi0n239puUNmMVlms0; X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ext Cullen Jennings' , 'IETF SIP List' , 'Francois Audet' , "Peterson, Jon" , '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 Brian Rosen wrote: >Okay, I'll take the bait. > >I think the problem with sips was the exception for last hop. Get rid of >that and sips means the UA requests end to end TLS and as far as we know, he >got it. > s/as far as we know/mistakenly believe/g The problem all along is that SIPS oversells itself by a huge and misleading amount. It is *not* like https which is what the uninformed luser is extremely likely to believe. While potentially great for rogue regimes bent on suspending 4th amendments, habeus corpuses and the like, it sucks for just about everybody else. If we have to keep it, at the very least let's call it something closer to the truth. Like, oh say, TURDBLOSSOM: or SHRUBS: >It's hop by hop, which means a transitive trust model, and >therefore subject to an untrustworthy proxy screwing up. Even with such >limitations, I think that is valuable. Needs some clarifications as has >been discussed. > >There may be other valuable security mechanisms to be proposed, but TLS end >to end is useful. > >I am NOT in favor of deprecating sips. > > My sense is there will be between 0 and 1 widely deployed e2e crypto mechanmism for SIP. Choose wisely. 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 Oct 27 11:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTvl-0000v2-TD; Fri, 27 Oct 2006 11:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTvk-0000uE-7P for sip@ietf.org; Fri, 27 Oct 2006 11:47:36 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdTvf-0000NE-SW for sip@ietf.org; Fri, 27 Oct 2006 11:47:36 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E1D021E8C28; Fri, 27 Oct 2006 08:47:30 -0700 (PDT) To: "Joel M. Halpern" Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 08:47:30 -0700 In-Reply-To: <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> (Joel M. Halpern's message of "Fri, 27 Oct 2006 11:37:37 -0400") Message-ID: <861wotoj59.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: 'IETF SIP List' 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 "Joel M. Halpern" writes: > So let me ask a question. Maybe a stupid question. > You are sending a SIP invite to someone. You want it secured. Let's > suppose you want it secured end to end. Let's even suppose that if it > is not secured end to end you want it ti fail. So you specify SIPS in > accordance with your definition. > > Do you really want that call to fail because two of the proxies in the > path are using IPSec instead of TLS? Well, I do. The security (authentication) properties of IPsec are rather different then those of TLS. And why just say IPsec is OK. What about WEP? What Once you relax the meaning to "secure" then it's more or ess meaningless. -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 Oct 27 12:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH4-0008U5-JB; Fri, 27 Oct 2006 12:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH3-0008SA-3B for sip@ietf.org; Fri, 27 Oct 2006 12:09:37 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUDK-0003uV-Ch for sip@ietf.org; Fri, 27 Oct 2006 12:05:50 -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 k9RG5gp00497; Fri, 27 Oct 2006 12:05: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] RE: TLS meaning Date: Fri, 27 Oct 2006 11:05:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCF80@zrc2hxm0.corp.nortel.com> In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAhBdA From: "Francois Audet" To: "EKR" , "Joel M. Halpern" 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 Exactly. And what about if the proxy is using my-homegrown-security-mechanism, which I unilateraly declare to be secure?=20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Friday, October 27, 2006 8:48 AM > To: Joel M. Halpern > Cc: 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning >=20 > "Joel M. Halpern" writes: >=20 > > So let me ask a question. Maybe a stupid question. > > You are sending a SIP invite to someone. You want it=20 > secured. Let's=20 > > suppose you want it secured end to end. Let's even suppose=20 > that if it=20 > > is not secured end to end you want it ti fail. So you=20 > specify SIPS in=20 > > accordance with your definition. > > > > Do you really want that call to fail because two of the=20 > proxies in the=20 > > path are using IPSec instead of TLS? >=20 > Well, I do. The security (authentication) properties of IPsec=20 > are rather different then those of TLS. And why just say=20 > IPsec is OK. What about WEP? What Once you relax the meaning=20 > to "secure" then it's more or ess meaningless.=20 >=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=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 Oct 27 12:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH0-0008Qh-EL; Fri, 27 Oct 2006 12:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUGz-0008Lf-0J for sip@ietf.org; Fri, 27 Oct 2006 12:09:33 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUF5-0004Ha-Qv for sip@ietf.org; Fri, 27 Oct 2006 12:07:37 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5D9CA1E8C28; Fri, 27 Oct 2006 09:07:35 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45422E35.8020403@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:07:35 -0700 In-Reply-To: <45422E35.8020403@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 09:05:09 -0700") Message-ID: <86mz7hn3nc.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: >>Well, I do. The security (authentication) properties of IPsec are rather >>different then those of TLS. And why just say IPsec is OK. What about >> WEP? What Once you relax the meaning to "secure" then it's more or >> ess meaningless. >> > One could say that when you explictly allow for unexpected MITM attacks, the > meaning is pretty much useless. Which is SIPS in a nutshell. One could say it, but of course it would be wrong. -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 Oct 27 12:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH4-0008U5-JB; Fri, 27 Oct 2006 12:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH3-0008SA-3B for sip@ietf.org; Fri, 27 Oct 2006 12:09:37 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUDK-0003uV-Ch for sip@ietf.org; Fri, 27 Oct 2006 12:05:50 -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 k9RG5gp00497; Fri, 27 Oct 2006 12:05: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] RE: TLS meaning Date: Fri, 27 Oct 2006 11:05:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCF80@zrc2hxm0.corp.nortel.com> In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAhBdA From: "Francois Audet" To: "EKR" , "Joel M. Halpern" 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 Exactly. And what about if the proxy is using my-homegrown-security-mechanism, which I unilateraly declare to be secure?=20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: Friday, October 27, 2006 8:48 AM > To: Joel M. Halpern > Cc: 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning >=20 > "Joel M. Halpern" writes: >=20 > > So let me ask a question. Maybe a stupid question. > > You are sending a SIP invite to someone. You want it=20 > secured. Let's=20 > > suppose you want it secured end to end. Let's even suppose=20 > that if it=20 > > is not secured end to end you want it ti fail. So you=20 > specify SIPS in=20 > > accordance with your definition. > > > > Do you really want that call to fail because two of the=20 > proxies in the=20 > > path are using IPSec instead of TLS? >=20 > Well, I do. The security (authentication) properties of IPsec=20 > are rather different then those of TLS. And why just say=20 > IPsec is OK. What about WEP? What Once you relax the meaning=20 > to "secure" then it's more or ess meaningless.=20 >=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=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 Oct 27 12:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH0-0008Qh-EL; Fri, 27 Oct 2006 12:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUGz-0008Lf-0J for sip@ietf.org; Fri, 27 Oct 2006 12:09:33 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUF5-0004Ha-Qv for sip@ietf.org; Fri, 27 Oct 2006 12:07:37 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5D9CA1E8C28; Fri, 27 Oct 2006 09:07:35 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45422E35.8020403@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:07:35 -0700 In-Reply-To: <45422E35.8020403@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 09:05:09 -0700") Message-ID: <86mz7hn3nc.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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: >>Well, I do. The security (authentication) properties of IPsec are rather >>different then those of TLS. And why just say IPsec is OK. What about >> WEP? What Once you relax the meaning to "secure" then it's more or >> ess meaningless. >> > One could say that when you explictly allow for unexpected MITM attacks, the > meaning is pretty much useless. Which is SIPS in a nutshell. One could say it, but of course it would be wrong. -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 Oct 27 12:11:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUGs-0008Nn-Dw; Fri, 27 Oct 2006 12:09:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUGr-0008Lf-Df for sip@ietf.org; Fri, 27 Oct 2006 12:09:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUGe-0004XD-Kw for sip@ietf.org; Fri, 27 Oct 2006 12:09:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 09:09:12 -0700 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 k9RG9CDo023981; Fri, 27 Oct 2006 09:09:12 -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 k9RG9BW4019152; Fri, 27 Oct 2006 09:09:11 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-306.cisco.com [10.21.153.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RFucE4015271; Fri, 27 Oct 2006 08:56:38 -0700 Message-ID: <45422F2C.2080300@cisco.com> Date: Fri, 27 Oct 2006 09:09:16 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> In-Reply-To: <86u01pn3u3.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; 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=1590; t=1161965352; x=1162829352; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=Ncm0RlNevmUNfE4z9VQkfPiqx0QIALu3ZWyrOfIUEeDOsT17d+j4Z1uU7BSjQ8d/LFMqckfM oQn9Y5ZDBm3rhGxVlGzitDvOXCFr/TrxQXzdcRccaBrkq8fLflsMcxNy; X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Eric Rescorla wrote: >Michael Thomas writes: > > > >>Brian Rosen wrote: >> >> >> >>>Okay, I'll take the bait. >>> >>>I think the problem with sips was the exception for last hop. Get rid of >>>that and sips means the UA requests end to end TLS and as far as we know, he >>>got it. >>> >>> >>> >>s/as far as we know/mistakenly believe/g >> >>The problem all along is that SIPS oversells itself by a huge and >>misleading amount. >>It is *not* like https which is what the uninformed luser is extremely >>likely to believe. >>While potentially great for rogue regimes bent on suspending 4th >>amendments, habeus >>corpuses and the like, it sucks for just about everybody else. If we >>have to keep it, at the >>very least let's call it something closer to the truth. Like, oh say, >>TURDBLOSSOM: >>or SHRUBS: >> >> > >Well, I have no idea how SIPS sells itself > Gosh, maybe the same as, oh say, HTTPS? >, and I'm certainly >in favor of of end-to-end security mechanisms. However, >I don't think that that means that SIP over TLS has minimal >value > This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism. >, and since it's something that we already know how to do, >I consider it worth doing while we figure out how to deploy >the better stuff. > > Well, we manifestly do *not* know how to even do SIPS, hence our still talking about it 5 years out. Instead of trying yet again to polish this turd, why don't we... you know... look for some better stuff? 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 Oct 27 12:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUHb-0000DI-Pc; Fri, 27 Oct 2006 12:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUHa-0000D5-It for sip@ietf.org; Fri, 27 Oct 2006 12:10:10 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUHW-0005HH-8U for sip@ietf.org; Fri, 27 Oct 2006 12:10:10 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RFDUne029866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 10:13:32 -0500 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F43CA84@zrc2hxm2.corp.nortel.com> References: <62B9B0847CC47543B6B3B5E26BD268E60F43CA84@zrc2hxm2.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FB7A369-1601-4642-811F-37DDEBE3C168@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 11:09:58 -0500 To: Samir Srivastava X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List , Francois Audet , 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 On Oct 26, 2006, at 3:07 PM, Samir Srivastava wrote: > What about DCCP in Page mode IM that has the congestion control. > You can > run DTLS over that too. > Fair enough. I'd also say that sips: should work with DTLS/DCCP as well as DTLS/UDP, if we're going to allow UDP and DCCP transports for SIP.. The basic argument is that there are a number (perhaps relatively large, perhaps quite limited but possibly extensible) of transport alternatives that provide cryptographic functionality and protections equivalent to TLS, but may be more or less suitable for different deployment scenarios. The "real world end user" just wants to know "it is secured". But real-world environments often mix base deployment scenarios -- for example, a user on a mobile phone may be calling one on a wired Internet connection. By keeping sips: restricted to basic TLS, we essentially preclude users in the mixed scenarios from being able to request secure handling. This is self-defeating, and likely to prevent the widespread deployment and usage of sips:, which I think would be a horrible 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 Oct 27 12:12:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUHA-00006S-Vm; Fri, 27 Oct 2006 12:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH5-0008Su-MJ for sip@ietf.org; Fri, 27 Oct 2006 12:09:39 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUBA-0003Xg-VR for sip@ietf.org; Fri, 27 Oct 2006 12:03:36 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4632F1E8C28; Fri, 27 Oct 2006 09:03:32 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:03:32 -0700 In-Reply-To: <45422830.4040700@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 08:39:28 -0700") Message-ID: <86u01pn3u3.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: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Michael Thomas writes: > Brian Rosen wrote: > >>Okay, I'll take the bait. >> >>I think the problem with sips was the exception for last hop. Get rid of >>that and sips means the UA requests end to end TLS and as far as we know, he >> got it. >> > s/as far as we know/mistakenly believe/g > > The problem all along is that SIPS oversells itself by a huge and > misleading amount. > It is *not* like https which is what the uninformed luser is extremely > likely to believe. > While potentially great for rogue regimes bent on suspending 4th > amendments, habeus > corpuses and the like, it sucks for just about everybody else. If we > have to keep it, at the > very least let's call it something closer to the truth. Like, oh say, > TURDBLOSSOM: > or SHRUBS: Well, I have no idea how SIPS sells itself, and I'm certainly in favor of of end-to-end security mechanisms. However, I don't think that that means that SIP over TLS has minimal value, and since it's something that we already know how to do, I consider it worth doing while we figure out how to deploy the better stuff. -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 Oct 27 12:14:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUJq-0002nZ-1D; Fri, 27 Oct 2006 12:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUJo-0002kl-0F for sip@ietf.org; Fri, 27 Oct 2006 12:12:28 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUJh-0005br-UB for sip@ietf.org; Fri, 27 Oct 2006 12:12:27 -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 k9RGCJM07778 for ; Fri, 27 Oct 2006 12:12: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] RE: TLS meaning Date: Fri, 27 Oct 2006 11:12:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCCFA6@zrc2hxm0.corp.nortel.com> In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/g From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 case people having noticed, it is looking like we are having a mailing list=20 hum on the following 2 questions: 1 - Do you favour deprecating the sips scheme altogether (yes/no) 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) Note: Voting Yes on 2 does not necessarily imply you are voting No on 1, but it will only make sense if sips is not deprecated. I'm keeping track of the vote. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 12:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdULB-0004hd-Cj; Fri, 27 Oct 2006 12:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUL9-0004fh-Pm for sip@ietf.org; Fri, 27 Oct 2006 12:13:51 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUL7-0005tD-F8 for sip@ietf.org; Fri, 27 Oct 2006 12:13:51 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D3B9A1E8C28; Fri, 27 Oct 2006 09:13:48 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:13:48 -0700 In-Reply-To: <45422F2C.2080300@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 09:09:16 -0700") Message-ID: <86iri5n3cz.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: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Michael Thomas writes: > Eric Rescorla wrote: >>Well, I have no idea how SIPS sells itself >> > Gosh, maybe the same as, oh say, HTTPS? Gosh, I don't know. I don't go around saying that, and if you find me someone saying that I'd be happy to correct them. >>, and I'm certainly >>in favor of of end-to-end security mechanisms. However, >>I don't think that that means that SIP over TLS has minimal >>value >> > > This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism. Which is what SIPS is: a hopwise mechanism with a requirement that each hop do the same thing. >>, and since it's something that we already know how to do, >>I consider it worth doing while we figure out how to deploy >> the better stuff. >> > Well, we manifestly do *not* know how to even do SIPS, hence our still > talking > about it 5 years out. No, I don't agree with that. I think we got it wrong the first time but have a fairly good understanding of how to do it now. > Instead of trying yet again to polish this turd, > why don't we... > you know... look for some better stuff? Go ahead and suggest something. All I see you doing now is complaining. -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 Oct 27 12:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdULi-0004vZ-Iv; Fri, 27 Oct 2006 12:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdULg-0004tK-PF for sip@ietf.org; Fri, 27 Oct 2006 12:14:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdULf-0005yd-Fh for sip@ietf.org; Fri, 27 Oct 2006 12:14:24 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RFHrht029934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 10:17:54 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DBCC88E@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 27 Oct 2006 11:14:21 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List Subject: [Sip] Re: TLS meaning X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 26, 2006, at 4:15 PM, Francois Audet wrote: > Hi Dean, > > I'm OK with using other protocols (including DTLS and IPsec) to secure > signalling, but I don't see why you'd need to use SIPS for that. > That's a fair question. I'd argue that the answer is "We would use sips: because that is the current mechanism by which and end user requests secure handling of signaling, indicating that if the other nodes cannot provide secure handling that the call is to fail rather than be handled insecurely" and "because it is important that users be able to demand this distinct handling model". I suppose we could replace this with an option-tag in Require and Proxy-Require, and that if we did, we could just deprecate sips: completely. Now that I think of it this way, this might be a much better general mechanism anyhow, much closer to our usual negotiation model. -- 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 Oct 27 12:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUO4-0006YX-Vc; Fri, 27 Oct 2006 12:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUO3-0006XR-O1 for sip@ietf.org; Fri, 27 Oct 2006 12:16:51 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUO1-0006UN-0J for sip@ietf.org; Fri, 27 Oct 2006 12:16:51 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 681F01E8C28; Fri, 27 Oct 2006 09:16:48 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] RE: TLS meaning References: <62B9B0847CC47543B6B3B5E26BD268E60F43CA84@zrc2hxm2.corp.nortel.com> <6FB7A369-1601-4642-811F-37DDEBE3C168@softarmor.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:16:48 -0700 In-Reply-To: <6FB7A369-1601-4642-811F-37DDEBE3C168@softarmor.com> (Dean Willis's message of "Fri, 27 Oct 2006 11:09:58 -0500") Message-ID: <86ejstn37z.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List , Francois Audet , Aki Niemi 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 Oct 26, 2006, at 3:07 PM, Samir Srivastava wrote: >> What about DCCP in Page mode IM that has the congestion control. >> You can >> run DTLS over that too. >> > > > Fair enough. I'd also say that sips: should work with DTLS/DCCP as > well as DTLS/UDP, if we're going to allow UDP and DCCP transports for > SIP.. > > The basic argument is that there are a number (perhaps relatively > large, perhaps quite limited but possibly extensible) of transport > alternatives that provide cryptographic functionality and protections > equivalent to TLS, but may be more or less suitable for different > deployment scenarios. I think there's a pretty bright line between DTLS, which is primarily TLS over a different transport and IPsec, SSH, etc. which are different security protocols with some similarities to TLS and some not. To consider only one issue, how you identify the peer is rather different for all these protocols. -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 Oct 27 12:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH6-0008Vo-2I; Fri, 27 Oct 2006 12:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUH3-0008SA-Jq for sip@ietf.org; Fri, 27 Oct 2006 12:09:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUCm-0003pB-A3 for sip@ietf.org; Fri, 27 Oct 2006 12:05:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2006 09:05:11 -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 k9RG5BFS018415; Fri, 27 Oct 2006 09:05:11 -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 k9RG5Bin016212; Fri, 27 Oct 2006 09:05:11 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-306.cisco.com [10.21.153.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RFqWpl015175; Fri, 27 Oct 2006 08:52:35 -0700 Message-ID: <45422E35.8020403@cisco.com> Date: Fri, 27 Oct 2006 09:05:09 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; 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=932; t=1161965111; x=1162829111; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=pKE8PVelawKPj8vuAjhldUeLNE11t8M6sTzz687SDlRVU8UoRRaV4on44WAjIBZF3slOB/Z7 STdMOBZxtK1UkvlvwdO/b6yhx9ZWfbpHStV8r/gD30+PJeFO2wIcxCTz; X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Joel M. Halpern" , '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 Eric Rescorla wrote: >"Joel M. Halpern" writes: > > > >>So let me ask a question. Maybe a stupid question. >>You are sending a SIP invite to someone. You want it secured. Let's >>suppose you want it secured end to end. Let's even suppose that if it >>is not secured end to end you want it ti fail. So you specify SIPS in >>accordance with your definition. >> >>Do you really want that call to fail because two of the proxies in the >>path are using IPSec instead of TLS? >> >> > >Well, I do. The security (authentication) properties of IPsec are rather >different then those of TLS. And why just say IPsec is OK. What about >WEP? What Once you relax the meaning to "secure" then it's more or >ess meaningless. > > One could say that when you explictly allow for unexpected MITM attacks, the meaning is pretty much useless. Which is SIPS in a nutshell. 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 Oct 27 12:22:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdURj-0008NT-1M; Fri, 27 Oct 2006 12:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdURh-0008NH-Pu for sip@ietf.org; Fri, 27 Oct 2006 12:20:37 -0400 Received: from web31801.mail.mud.yahoo.com ([68.142.207.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdURd-0007D8-Da for sip@ietf.org; Fri, 27 Oct 2006 12:20:37 -0400 Received: (qmail 60538 invoked by uid 60001); 27 Oct 2006 16:20:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MTcC4/V/iHr+Ch8QwMV1TMMHb5cGt1xsHEUZfyud3O/hgckrZVoLlkH8YwT8OMrQTKbquP1+JeLSE1bGjyL2labw78b+aCKOiWfO/gbqY7ibvBJcPafXRtGykd/X75M+DrwPZuIfQ/p2dVhsfxnFIazgADUapns0AMrwg0uqwn8= ; X-YMail-OSG: ewLWIAkVM1mvTzK6axAbDjw10YV8zf.EX8OlcEL2CGT_ODiTSsRGNdiqqdNQhGS75Q-- Received: from [24.61.86.235] by web31801.mail.mud.yahoo.com via HTTP; Fri, 27 Oct 2006 09:20:16 PDT Date: Fri, 27 Oct 2006 09:20:16 -0700 (PDT) From: Dan Petrie Subject: RE: [Sip] RE: TLS meaning To: Francois Audet , IETF SIP List In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCFA6@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <795410.59589.qm@web31801.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 --- Francois Audet wrote: > In case people having noticed, it is looking like we are having a > mailing list > hum on the following 2 questions: > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) no > 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) yes SIPez LLC SIP VoIP, IM and Presence Consulting http:/www.sipez.com tel: +1 (617) 273-4000 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 12:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUU6-0002fc-8x; Fri, 27 Oct 2006 12:23:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUU5-0002cp-CE for sip@ietf.org; Fri, 27 Oct 2006 12:23:05 -0400 Received: from celine.siteprotect.com ([64.26.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUU0-0007e7-FZ for sip@ietf.org; Fri, 27 Oct 2006 12:23:05 -0400 Received: from cornfed (c-24-9-79-73.hsd1.co.comcast.net [24.9.79.73]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k9RGMsR04931; Fri, 27 Oct 2006 11:22:54 -0500 Message-Id: <200610271622.k9RGMsR04931@celine.siteprotect.com> From: "Frank W. Miller" To: "'Francois Audet'" , "'IETF SIP List'" Subject: RE: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 10:22:49 -0600 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.2962 Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAAB8dvA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCCFA6@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Inline... FM -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Friday, October 27, 2006 10:12 AM To: IETF SIP List Subject: RE: [Sip] RE: TLS meaning In case people having noticed, it is looking like we are having a mailing list hum on the following 2 questions: 1 - Do you favour deprecating the sips scheme altogether (yes/no) Yes. The SIPS scheme does not provided end-to-end security and worse, it can be mistaken by the uneducated as doing that when it doesn't. SIP needs a true UA-to-UA security scheme. 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) N/A Note: Voting Yes on 2 does not necessarily imply you are voting No on 1, but it will only make sense if sips is not deprecated. I'm keeping track of the vote. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 Oct 27 12:37:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUfk-0001rl-NX; Fri, 27 Oct 2006 12:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUfj-0001rf-4S for sip@ietf.org; Fri, 27 Oct 2006 12:35:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUfh-0000rc-Qw for sip@ietf.org; Fri, 27 Oct 2006 12:35:07 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RFcXnm030205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 10:38:33 -0500 In-Reply-To: <17730.9269.969078.267012@harjus.tutpro.com> References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <8664e5ooho.fsf@raman.networkresonance.com> <17730.9269.969078.267012@harjus.tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 11:35:01 -0500 To: Juha Heinanen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'ext Cullen Jennings' , 'Michael Thomas' , "Peterson, Jon" , '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 On Oct 27, 2006, at 10:22 AM, Juha Heinanen wrote: > Eric Rescorla writes: > >> At the time it was accepted, the last-hop exception seemed sensible >> (by analogy to the last-hop HTTPS accelerators used in many >> data centers), but as we've seen that produces problems and >> the need for it can be removed with outbound. I haven't >> seen any arguments I find convincing that that's not the way >> to go. > > there was lots of opposition when someone (i think jonathan) proposed > that SIPS means tls on every hop, i.e., if the route through proxies > cannot implement it, then the request must fail. i personally would > have been happy with this interpretation. As the source of much of the vocalization of that opposition, let me see if I can recover the argument. Requiring TLS end-to-end either means: 1) The UAS have an established TLS connection to a proxy, which is then re-used, or 2) The UAS be able to receive a new TLS connection, meaning for all practical purposes that it has to have a cert that can be recognized by the requestor, which could be either the UAC or an intermediate proxy. And of course, requiring TLS means that all UAs must implement TCP. While this is in the spec, it isn't in the real-world, and many of the mobile people have advanced arguments (that might or might not be correct) about the undesirability of TCP in low-power mobile applications, especially when they already have an IPSEC SA established to their proxies. Outbound gives us an answer to requirement #1. As to #2, I suppose we could have a reasonably deployable variation of outbound where the outbound proxy or its infrastructure issues a cert to the UAS, such that the TLS connection could be opened proxy- to-UAS instead of UAS-to-proxy. This would have the advantage of allowing the TLS connection to be established on a per-call basis. Vijay, Francois and I have also proposed an alternative that uses HTTP-like transparent TLS proxy support instead of hop-by-hop, but this requires some form of mutual authentication UA-to-UA to be effective, and some people think that's really hard. But so far we have no consensus on the "TCP unsuitable for mobiles" question. I really don't want to see 2 billion mobile users unable to request or receive calls to or from traditional Internet users, where the traditional Internet user really needs the perceived security of sips:. -- 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 Oct 27 12:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUiF-0004Ni-Tg; Fri, 27 Oct 2006 12:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUiE-0004NR-Ds for sip@ietf.org; Fri, 27 Oct 2006 12:37:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUiA-0001L9-Iz for sip@ietf.org; Fri, 27 Oct 2006 12:37:42 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RFe9Hc030228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 10:41:09 -0500 In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 11:37:37 -0500 To: EKR X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Joel M. Halpern" , '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 Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > "Joel M. Halpern" writes: > >> So let me ask a question. Maybe a stupid question. >> You are sending a SIP invite to someone. You want it secured. Let's >> suppose you want it secured end to end. Let's even suppose that >> if it >> is not secured end to end you want it ti fail. So you specify >> SIPS in >> accordance with your definition. >> >> Do you really want that call to fail because two of the proxies in >> the >> path are using IPSec instead of TLS? > > Well, I do. The security (authentication) properties of IPsec are > rather > different then those of TLS. And why just say IPsec is OK. What about > WEP? What Once you relax the meaning to "secure" then it's more or > ess meaningless. Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? -- 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 Oct 27 12:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUnc-0002wB-Bx; Fri, 27 Oct 2006 12:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUna-0002uX-7p for sip@ietf.org; Fri, 27 Oct 2006 12:43:14 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUnY-00029X-RN for sip@ietf.org; Fri, 27 Oct 2006 12:43:14 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 2E8D31E8C28; Fri, 27 Oct 2006 09:43:12 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <8664e5ooho.fsf@raman.networkresonance.com> <17730.9269.969078.267012@harjus.tutpro.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:43:12 -0700 In-Reply-To: (Dean Willis's message of "Fri, 27 Oct 2006 11:35:01 -0500") Message-ID: <868xj1n1zz.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: 52f7a77164458f8c7b36b66787c853da Cc: 'ext Cullen Jennings' , 'Michael Thomas' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , Juha Heinanen 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 Oct 27, 2006, at 10:22 AM, Juha Heinanen wrote: > >> Eric Rescorla writes: >> >>> At the time it was accepted, the last-hop exception seemed sensible >>> (by analogy to the last-hop HTTPS accelerators used in many >>> data centers), but as we've seen that produces problems and >>> the need for it can be removed with outbound. I haven't >>> seen any arguments I find convincing that that's not the way >>> to go. >> >> there was lots of opposition when someone (i think jonathan) proposed >> that SIPS means tls on every hop, i.e., if the route through proxies >> cannot implement it, then the request must fail. i personally would >> have been happy with this interpretation. > > As the source of much of the vocalization of that opposition, let me > see if I can recover the argument. > > Requiring TLS end-to-end either means: > > 1) The UAS have an established TLS connection to a proxy, which is > then re-used, or > > 2) The UAS be able to receive a new TLS connection, meaning for all > practical purposes that it has to have a cert that can be recognized > by the requestor, which could be either the UAC or an intermediate > proxy. > > And of course, requiring TLS means that all UAs must implement TCP. Well, or standardizing SIP/DTLS. While I don't think it makes sense to allow SIPS to mean "SIP over anything secure", I don't see a similar problem with it meaning "SIP over TLS or SIP over DTLS" > Outbound gives us an answer to requirement #1. Yeah, I think this is the right answer. > As to #2, I suppose we could have a reasonably deployable variation > of outbound where the outbound proxy or its infrastructure issues a > cert to the UAS, such that the TLS connection could be opened proxy- > to-UAS instead of UAS-to-proxy. Another way to do this would be to relax not the TLS requirement for the last hop but the requirement to identify the UAC with a certificate rather than Digest. The details are a bit complicated, though. > This would have the advantage of > allowing the TLS connection to be established on a per-call basis. > Vijay, Francois and I have also proposed an alternative that uses > HTTP-like transparent TLS proxy support instead of hop-by-hop, but > this requires some form of mutual authentication UA-to-UA to be > effective, and some people think that's really hard. That's far from the only problem--unless you think that proxies pretty much don't do anything useful besides transparently route traffic. -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 Oct 27 12:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUoo-0007Cm-OW; Fri, 27 Oct 2006 12:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUon-00079G-3x for sip@ietf.org; Fri, 27 Oct 2006 12:44:29 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUol-0002K3-Qn for sip@ietf.org; Fri, 27 Oct 2006 12:44:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4737E1E8C28; Fri, 27 Oct 2006 09:44:27 -0700 (PDT) To: Dean Willis Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 09:44:27 -0700 In-Reply-To: <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> (Dean Willis's message of "Fri, 27 Oct 2006 11:37:37 -0500") Message-ID: <864ptpn1xw.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: "Joel M. Halpern" , 'IETF SIP List' 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 Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: >> Well, I do. The security (authentication) properties of IPsec are >> rather >> different then those of TLS. And why just say IPsec is OK. What about >> WEP? What Once you relax the meaning to "secure" then it's more or >> ess meaningless. > > Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? No, I don't see a problem with that. It seems to me that (D)TLS over any transport has basically the same security properties, which is the relevant issue here. -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 Oct 27 13:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVHc-0000Pl-Uk; Fri, 27 Oct 2006 13:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVHb-0000Pf-P1 for sip@ietf.org; Fri, 27 Oct 2006 13:14:15 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVHa-0007MF-9P for sip@ietf.org; Fri, 27 Oct 2006 13:14:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdVH2-0002CF-Cv; Fri, 27 Oct 2006 12:13:53 -0500 From: "Brian Rosen" To: "'EKR'" , "'Dean Willis'" Subject: RE: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 13:13:41 -0400 Message-ID: <069301c6f9eb$4abb0880$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb552Vd24CObBwwQuG5eBQUs5e5ngAA6uFw In-Reply-To: <864ptpn1xw.fsf@raman.networkresonance.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 - [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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "'Joel M. Halpern'" , '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 Yeah, I can go along with that. BTW Francois: 1) no 2) yes Brian > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Friday, October 27, 2006 12:44 PM > To: Dean Willis > Cc: Joel M. Halpern; 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning > > Dean Willis writes: > > On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >> Well, I do. The security (authentication) properties of IPsec are > >> rather > >> different then those of TLS. And why just say IPsec is OK. What about > >> WEP? What Once you relax the meaning to "secure" then it's more or > >> ess meaningless. > > > > Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? > > No, I don't see a problem with that. It seems to me that (D)TLS over > any transport has basically the same security properties, which > is the relevant issue here. > > -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 Oct 27 13:30:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVUZ-0002EB-ES; Fri, 27 Oct 2006 13:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVUX-0002E5-TQ for sip@ietf.org; Fri, 27 Oct 2006 13:27:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVUW-0000pn-K9 for sip@ietf.org; Fri, 27 Oct 2006 13:27:37 -0400 Received: from [192.168.1.101] (adsl-75-34-132-93.dsl.hstntx.sbcglobal.net [75.34.132.93]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RGV6PO031251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 11:31:07 -0500 In-Reply-To: <864ptpn1xw.fsf@raman.networkresonance.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 12:27:34 -0500 To: EKR X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Joel M. Halpern" , '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 Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > Dean Willis writes: >> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: >>> Well, I do. The security (authentication) properties of IPsec are >>> rather >>> different then those of TLS. And why just say IPsec is OK. What >>> about >>> WEP? What Once you relax the meaning to "secure" then it's more or >>> ess meaningless. >> >> Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? > > No, I don't see a problem with that. It seems to me that (D)TLS over > any transport has basically the same security properties, which > is the relevant issue here. That's useful to know. It might be possible to persuade the UDP fans in mobile land to use DTLS. I'm hearing good things about DTLS from other folks who have played with it on small systems. And I can clearly see that a blanket policy that would accept WEP as "Secured" would be bad. But please help us understand what's different about IPSEC usage in the IMS sense. IMS has a persistent IPSEC SA established between the edge proxy and the UA. Authentication is accomplished using the SIM as a token generator, and the crypto is one of the usual mechanisms (keep in mind TLS still allows plain small-key DES, which isn't all that strong). The applications are constructed so that the SIP function is aware of the SA and that it is connected to an authenticated party. What is different about the security properties here from TLS in outbound in such a way that it makes a difference to the SIP 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 Oct 27 13:59:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVxB-00055M-A7; Fri, 27 Oct 2006 13:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdVx9-00051F-M3 for sip@ietf.org; Fri, 27 Oct 2006 13:57:11 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdVx8-0005CT-9p for sip@ietf.org; Fri, 27 Oct 2006 13:57:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdVwy-0006JL-Qz; Fri, 27 Oct 2006 12:57:01 -0500 From: "Brian Rosen" To: "'Dean Willis'" , "'EKR'" Subject: RE: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 13:57:02 -0400 Message-ID: <06b501c6f9f1$51664810$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb57ZF7f1Bd85/pTemiaCWeaa9w5AAAjC7g In-Reply-To: <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.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 - [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: 0fa76816851382eb71b0a882ccdc29ac Cc: "'Joel M. Halpern'" , '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 There are a lot of mechanisms that can create a secure connection between two entities. It is often hard to equate the security properties of those mechanisms. Even between IPSEC and TLS, with the same ciphersuite, you don't have the same security properties. The problem I have is that then sips means "we think we have created something approximating what you asked for, by assembling a set of mechanisms across the hops, and we think you should be happy" I don't see how you admit IPSEC under some circumstances (and it would have to be fairly carefully locked down to a set of specific circumstances. For example, you can't allow the IPSEC tunnel to connect more than the two parties across a hop) and then say some other mechanisms are not allowed. For example suppose I had a military grade link encryptor and just a proxy on each end of the link. It's a slippery slope. It may be possible to create some new mechanism that describes the security properties required, and allows any mechanism that meets those properties at any hop. I don't think that is sips. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, October 27, 2006 1:28 PM > To: EKR > Cc: Joel M. Halpern; 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning > > > On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > > > Dean Willis writes: > >> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >>> Well, I do. The security (authentication) properties of IPsec are > >>> rather > >>> different then those of TLS. And why just say IPsec is OK. What > >>> about > >>> WEP? What Once you relax the meaning to "secure" then it's more or > >>> ess meaningless. > >> > >> Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? > > > > No, I don't see a problem with that. It seems to me that (D)TLS over > > any transport has basically the same security properties, which > > is the relevant issue here. > > That's useful to know. It might be possible to persuade the UDP fans > in mobile land to use DTLS. I'm hearing good things about DTLS from > other folks who have played with it on small systems. > > And I can clearly see that a blanket policy that would accept WEP as > "Secured" would be bad. > > But please help us understand what's different about IPSEC usage in > the IMS sense. > > IMS has a persistent IPSEC SA established between the edge proxy and > the UA. Authentication is accomplished using the SIM as a token > generator, and the crypto is one of the usual mechanisms (keep in > mind TLS still allows plain small-key DES, which isn't all that > strong). The applications are constructed so that the SIP function is > aware of the SA and that it is connected to an authenticated party. > > What is different about the security properties here from TLS in > outbound in such a way that it makes a difference to the SIP 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 14:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdW3o-0000TT-1P; Fri, 27 Oct 2006 14:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdW3l-0000TE-Vw for sip@ietf.org; Fri, 27 Oct 2006 14:04:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdW3j-0006P8-KY for sip@ietf.org; Fri, 27 Oct 2006 14:04:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 11:03:59 -0700 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 k9RI3xjh023038; Fri, 27 Oct 2006 11:03:59 -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 k9RI3lOd022001; Fri, 27 Oct 2006 11:03:56 -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); Fri, 27 Oct 2006 14:03:55 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:03:55 -0400 Message-ID: <45424A0B.8010903@cisco.com> Date: Fri, 27 Oct 2006 14:03:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> In-Reply-To: <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 18:03:55.0547 (UTC) FILETIME=[44A16EB0:01C6F9F2] DKIM-Signature: a=rsa-sha1; q=dns; l=1358; t=1161972239; x=1162836239; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D8T2qLW38YZ2FX38zFN0RkJYv1P0=3D; b=oa4cR7UsubZHxV/oZ86JLGkzVEvIvszltu+egQiSiA04H7G/FxXyIDHzyo9F8kLVNFhQ02va 3RhtFXjLUu3IZgVWyJXiwBY7r3NCTyUoP+5AjwO3yq6oRzOaNPKfnpeh; 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: 97adf591118a232206bdb5a27b217034 Cc: "Joel M. Halpern" , '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: > > On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >> "Joel M. Halpern" writes: >> >>> So let me ask a question. Maybe a stupid question. >>> You are sending a SIP invite to someone. You want it secured. Let's >>> suppose you want it secured end to end. Let's even suppose that if it >>> is not secured end to end you want it ti fail. So you specify SIPS in >>> accordance with your definition. >>> >>> Do you really want that call to fail because two of the proxies in the >>> path are using IPSec instead of TLS? In general, I want "best effort security", by which I mean I want a secure call if I can get it, else I want an insecure call. But I want to know for sure which I got, so I can make a decision about how I use it. Perhaps there could be multiple degrees of security, though in practice I don't think that will be sufficiently user friendly. And I can imagine some environments where only secure calls are acceptable and others should fail. But I think that is the exception rather than the rule. If the call is "secure", I don't much care what mechanism was used to achieve it. But I do want some assurance that I have received the degree of security that is being asserted. That could be via some combination of technologies and legal agreements. 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 Oct 27 14:14:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWBs-0004aP-8F; Fri, 27 Oct 2006 14:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWBq-0004YD-76 for sip@ietf.org; Fri, 27 Oct 2006 14:12:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWBH-0007lO-Ko for sip@ietf.org; Fri, 27 Oct 2006 14:12:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2006 11:11:47 -0700 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 k9RIBlW6018191; Fri, 27 Oct 2006 14:11: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 k9RIBkYL016132; Fri, 27 Oct 2006 14:11:47 -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, 27 Oct 2006 14:11:46 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 14:11:46 -0400 Message-ID: <45424BE1.7030403@cisco.com> Date: Fri, 27 Oct 2006 14:11:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> In-Reply-To: <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 18:11:46.0223 (UTC) FILETIME=[5D2CE3F0:01C6F9F3] DKIM-Signature: a=rsa-sha1; q=dns; l=2548; t=1161972707; x=1162836707; 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]=20RE=3A=20TLS=20meaning |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3D8T2qLW38YZ2FX38zFN0RkJYv1P0=3D; b=oxiCPE9mIjCIgSctedmljacd4azUB3xESMCLTxMdHswPleOJxSzVHTExbwwRbB26/tvCe3j0 G//z+ozetK4MaUtR2CWXnDVjMw3OMOc7WU9hVP78o4jvhFffO7IszBOc; 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Joel M. Halpern" , '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 OK, I know I am not sufficiently competent on security matters to comment here. Nevertheless I will try: It seems to me that if we are to have SIPS, then rather than tying it to TLS or (D)TLS, or just defining it as "some security mechanism", it ought to be tied to an extensible list of security mechanisms, with an IANA registry and a procedure for approving new ones. We can argue over the criteria that a new one must meet to qualify, but we won't have restricted how many answers there are. Paul Dean Willis wrote: > > On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > >> Dean Willis writes: >>> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: >>>> Well, I do. The security (authentication) properties of IPsec are >>>> rather >>>> different then those of TLS. And why just say IPsec is OK. What about >>>> WEP? What Once you relax the meaning to "secure" then it's more or >>>> ess meaningless. >>> >>> Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? >> >> No, I don't see a problem with that. It seems to me that (D)TLS over >> any transport has basically the same security properties, which >> is the relevant issue here. > > That's useful to know. It might be possible to persuade the UDP fans in > mobile land to use DTLS. I'm hearing good things about DTLS from other > folks who have played with it on small systems. > > And I can clearly see that a blanket policy that would accept WEP as > "Secured" would be bad. > > But please help us understand what's different about IPSEC usage in the > IMS sense. > > IMS has a persistent IPSEC SA established between the edge proxy and the > UA. Authentication is accomplished using the SIM as a token generator, > and the crypto is one of the usual mechanisms (keep in mind TLS still > allows plain small-key DES, which isn't all that strong). The > applications are constructed so that the SIP function is aware of the SA > and that it is connected to an authenticated party. > > What is different about the security properties here from TLS in > outbound in such a way that it makes a difference to the SIP 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 14:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWTO-0003FX-0f; Fri, 27 Oct 2006 14:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWSI-0002Qk-JO for sip@ietf.org; Fri, 27 Oct 2006 14:29:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWSC-0007qy-ES for sip@ietf.org; Fri, 27 Oct 2006 14:29:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GdWS0-0002n6-Us; Fri, 27 Oct 2006 13:29:05 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Dean Willis'" Subject: RE: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 14:29:05 -0400 Message-ID: <06c201c6f9f5$cc6a9a80$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb587N4UiCXaKedQKGSev8E7pQ42gAAVegQ In-Reply-To: <45424BE1.7030403@cisco.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 - [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: b5d20af10c334b36874c0264b10f59f1 Cc: "'Joel M. Halpern'" , '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 that is some new mechanism, that needs a lot of work, and it's not sips. It has value, but I don't think we know how to do that. I think we could engineer a solution, although probably not real soon. I would think you describe some set of properties you require, have some way to "vet" that a particular mechanism meets those properties, and then each hop can select among the available vetted mechanisms to meet the desired properties. I don't think agreeing on a suitable set of properties will be easy, and I don't think agreeing on how various tools we have map into those properties will be easy, but I think it may be possible. I would give that mechanism a new name, and it may be worthy of its own work group. In the mean time sips = TLS (or DTLS) on every hop is of value, and easily specified. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, October 27, 2006 2:12 PM > To: Dean Willis > Cc: Joel M. Halpern; 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning > > OK, I know I am not sufficiently competent on security matters to > comment here. Nevertheless I will try: > > It seems to me that if we are to have SIPS, then rather than tying it to > TLS or (D)TLS, or just defining it as "some security mechanism", it > ought to be tied to an extensible list of security mechanisms, with an > IANA registry and a procedure for approving new ones. We can argue over > the criteria that a new one must meet to qualify, but we won't have > restricted how many answers there are. > > Paul > > Dean Willis wrote: > > > > On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > > > >> Dean Willis writes: > >>> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >>>> Well, I do. The security (authentication) properties of IPsec are > >>>> rather > >>>> different then those of TLS. And why just say IPsec is OK. What about > >>>> WEP? What Once you relax the meaning to "secure" then it's more or > >>>> ess meaningless. > >>> > >>> Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? > >> > >> No, I don't see a problem with that. It seems to me that (D)TLS over > >> any transport has basically the same security properties, which > >> is the relevant issue here. > > > > That's useful to know. It might be possible to persuade the UDP fans in > > mobile land to use DTLS. I'm hearing good things about DTLS from other > > folks who have played with it on small systems. > > > > And I can clearly see that a blanket policy that would accept WEP as > > "Secured" would be bad. > > > > But please help us understand what's different about IPSEC usage in the > > IMS sense. > > > > IMS has a persistent IPSEC SA established between the edge proxy and the > > UA. Authentication is accomplished using the SIM as a token generator, > > and the crypto is one of the usual mechanisms (keep in mind TLS still > > allows plain small-key DES, which isn't all that strong). The > > applications are constructed so that the SIP function is aware of the SA > > and that it is connected to an authenticated party. > > > > What is different about the security properties here from TLS in > > outbound in such a way that it makes a difference to the SIP 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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 27 14:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWRk-0002KJ-B5; Fri, 27 Oct 2006 14:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWRi-0002CI-Ps for sip@ietf.org; Fri, 27 Oct 2006 14:28:46 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWOt-0004WZ-AG for sip@ietf.org; Fri, 27 Oct 2006 14:25:55 -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 k9RIPfq01720; Fri, 27 Oct 2006 14:25:41 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 13:25:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCD256@zrc2hxm0.corp.nortel.com> In-Reply-To: <06b501c6f9f1$51664810$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb57ZF7f1Bd85/pTemiaCWeaa9w5AAAjC7gAAFbb/A= From: "Francois Audet" To: "Brian Rosen" , "Dean Willis" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "Joel M. Halpern" , 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 Agree.=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, October 27, 2006 10:57 AM > To: 'Dean Willis'; 'EKR' > Cc: 'Joel M. Halpern'; 'IETF SIP List' > Subject: RE: [Sip] RE: TLS meaning >=20 > There are a lot of mechanisms that can create a secure=20 > connection between two entities. It is often hard to equate=20 > the security properties of those mechanisms. Even between=20 > IPSEC and TLS, with the same ciphersuite, you don't have the=20 > same security properties. =20 >=20 > The problem I have is that then sips means "we think we have=20 > created something approximating what you asked for, by=20 > assembling a set of mechanisms across the hops, and we think=20 > you should be happy" >=20 > I don't see how you admit IPSEC under some circumstances (and=20 > it would have to be fairly carefully locked down to a set of=20 > specific circumstances. For example, you can't allow the=20 > IPSEC tunnel to connect more than the two parties across a=20 > hop) and then say some other mechanisms are not allowed. > For example suppose I had a military grade link encryptor and=20 > just a proxy on each end of the link. It's a slippery slope. >=20 > It may be possible to create some new mechanism that=20 > describes the security properties required, and allows any=20 > mechanism that meets those properties at any hop. I don't=20 > think that is sips. >=20 > Brian >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Friday, October 27, 2006 1:28 PM > > To: EKR > > Cc: Joel M. Halpern; 'IETF SIP List' > > Subject: Re: [Sip] RE: TLS meaning > >=20 > >=20 > > On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > >=20 > > > Dean Willis writes: > > >> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > > >>> Well, I do. The security (authentication) properties of=20 > IPsec are=20 > > >>> rather different then those of TLS. And why just say=20 > IPsec is OK.=20 > > >>> What about WEP? What Once you relax the meaning to=20 > "secure" then=20 > > >>> it's more or ess meaningless. > > >> > > >> Would you want it to fail if DTLS/DCCP were used instead=20 > of TLS/TCP? > > > > > > No, I don't see a problem with that. It seems to me that=20 > (D)TLS over=20 > > > any transport has basically the same security properties,=20 > which is=20 > > > the relevant issue here. > >=20 > > That's useful to know. It might be possible to persuade the=20 > UDP fans=20 > > in mobile land to use DTLS. I'm hearing good things about DTLS from=20 > > other folks who have played with it on small systems. > >=20 > > And I can clearly see that a blanket policy that would=20 > accept WEP as=20 > > "Secured" would be bad. > >=20 > > But please help us understand what's different about IPSEC usage in=20 > > the IMS sense. > >=20 > > IMS has a persistent IPSEC SA established between the edge=20 > proxy and=20 > > the UA. Authentication is accomplished using the SIM as a token=20 > > generator, and the crypto is one of the usual mechanisms=20 > (keep in mind=20 > > TLS still allows plain small-key DES, which isn't all that strong).=20 > > The applications are constructed so that the SIP function=20 > is aware of=20 > > the SA and that it is connected to an authenticated party. > >=20 > > What is different about the security properties here from TLS in=20 > > outbound in such a way that it makes a difference to the SIP user? > >=20 > > -- > > Dean > >=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 Fri Oct 27 14:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWmV-0000l7-Aj; Fri, 27 Oct 2006 14:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWmT-0000kJ-MM for sip@ietf.org; Fri, 27 Oct 2006 14:50:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdWmR-00088m-Bf for sip@ietf.org; Fri, 27 Oct 2006 14:50:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so665346ugd for ; Fri, 27 Oct 2006 11:50:10 -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=Hm1rjjcurnm06cRfHeR/XAkyh1NV35O03xG0Kqug2M0/OlwVqU0Ns4kVCnPsWB6avR39ob1UHgeNGakY79yfiHXbg6aV6vAJvJCh4IZIHKSp2xekGFpj2ZJSqtWIMc7uI6asSk/Y11+kRDEaNEfEYIlLxg38c40ovTZGCUfnz94= Received: by 10.78.148.8 with SMTP id v8mr4989169hud; Fri, 27 Oct 2006 11:50:10 -0700 (PDT) Received: by 10.78.200.9 with HTTP; Fri, 27 Oct 2006 11:50:09 -0700 (PDT) Message-ID: <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> Date: Fri, 27 Oct 2006 11:50:10 -0700 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <86fydaoh2v.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, On 10/26/06, Eric Rescorla wrote: > I always have trouble learning from examples, so I hope you'll > forgive me if I've misunderstood. Of course. > It seems to me that there are three key points to this proposal: > > 1. The "limited-use" GRUU is tied to the long-term GRUU rather than > to an AOR. yes. one advantage IMO is that the lifetime of the limited-use GRUU is unrelated to the stability of the underlying connection. I can fetch a limited use GRUU, go into a tunnel, come out with a different IP address, and reregister my instance without having to refresh any of my limited-use GRUUs. > 2. The client explicitly controls limited-use GRUUs rather than > having them issued by the server as an automatic side effect yes. if I want a 5 minute validity GRUU or a week long validity GRUU I can get one and refresh (or not) independently. I can also get a GRUU that is limited use but still tied to my AOR. Possibly useful for allowing that pesky salesperson to bypass my call screening for a day or two about something important. As for load, the UA only generates load on the server when it needs something new. If the UA doesn't need any private GRUU, the server doesn't need to generate one. If the UA wants a unique GRUU per-call, the registrar does not need to do a full outbound-style registration (making and saving flow tokens, etc.) > 3. The client proposes the limited-use GRUU, not the server. no, the server still forms the actual lmited-use GRUU. thanks, -rohan > Do I have this correctly? > > The first seems perfectly reasonable. I'd have to think > about what advantages/disadvantages it had vis-a-vis current GRUU > approaches. The second seems fine, but I'm not sure it's really > that much of an improvement over the current approach. Why does > it significantly reduce the load on the server that you were > concerned about. The third point seems to have the significant > disadvantage that it requires the server to keep state for each > client-requested limited-use GRUU. I understood that reducing the > amount of server-side state was an an important consideration > for many... > > -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 Oct 27 15:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXKw-00065R-2b; Fri, 27 Oct 2006 15:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXKu-00064x-O6 for sip@ietf.org; Fri, 27 Oct 2006 15:25:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXKq-0001g9-9u for sip@ietf.org; Fri, 27 Oct 2006 15:25:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 12:25:43 -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 k9RJPhNN006344; Fri, 27 Oct 2006 12:25:43 -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 k9RJPhin006973; Fri, 27 Oct 2006 12:25:43 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn5-135.cisco.com [10.21.88.135]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RJD8eY019614; Fri, 27 Oct 2006 12:13:09 -0700 Message-ID: <45425D3C.3010308@cisco.com> Date: Fri, 27 Oct 2006 12:25:48 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> In-Reply-To: <861wotoj59.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; 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=1241; t=1161977143; x=1162841143; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=rpyxitZ3SU2O97MiZ0f5yRgBzL0YNv/3reiqyGSvGafi4T7s35ZwXvM66hq5+3u4h3DXIq+4 tDuGM9GIX5pZuQUk2xiGmsKWTRjOYP9a/vU+geU3z4mwofKeQoOJqip7; X-Spam-Score: 1.8 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Joel M. Halpern" , '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 Eric Rescorla wrote: >"Joel M. Halpern" writes: > > > >>So let me ask a question. Maybe a stupid question. >>You are sending a SIP invite to someone. You want it secured. Let's >>suppose you want it secured end to end. Let's even suppose that if it >>is not secured end to end you want it ti fail. So you specify SIPS in >>accordance with your definition. >> >>Do you really want that call to fail because two of the proxies in the >>path are using IPSec instead of TLS? >> >> > >Well, I do. The security (authentication) properties of IPsec are rather >different then those of TLS. And why just say IPsec is OK. What about >WEP? What Once you relax the meaning to "secure" then it's more or >ess meaningless. > > > This is true even with TLS: you can have wildly different security properties between two TLS sessions. SIPS happily paves over those differences with the in context meaningless word "secure". Let's put it this way: if you were charged with determining whether a system was adequately defended would SIPS *alone* tell you anything useful about its worthiness to withstand attacks? I claim not. That's pretty different than HTTPS. 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 Oct 27 15:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLT-00071l-55; Fri, 27 Oct 2006 15:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXLR-0006be-JF for sip@ietf.org; Fri, 27 Oct 2006 15:26:21 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdX77-0006s9-WB for sip@ietf.org; Fri, 27 Oct 2006 15:11:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2006 12:11:34 -0700 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 k9RJBXNm031276; Fri, 27 Oct 2006 15:11:33 -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 k9RJBUDm010101; Fri, 27 Oct 2006 15:11:33 -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); Fri, 27 Oct 2006 15:11:31 -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] Re: TLS meaning Date: Fri, 27 Oct 2006 15:11:27 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3021F21E3@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: TLS meaning Thread-Index: Acb55R0Sa5exioSeSbWFE8AUnC2bmQAFdhew From: "Michael Hammer \(mhammer\)" To: "Dean Willis" , "Francois Audet" X-OriginalArrivalTime: 27 Oct 2006 19:11:31.0357 (UTC) FILETIME=[B614ECD0:01C6F9FB] DKIM-Signature: a=rsa-sha1; q=dns; l=2074; t=1161976293; x=1162840293; 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]=20Re=3A=20TLS=20meaning |To:=22Dean=20Willis=22=20, =0A=20=20=20=20=20=20= 20=20=22Francois=20Audet=22=20; X=v=3Dcisco.com=3B=20h=3DRhCVH0kIHaLaCD1Pw76mG9MpFWs=3D; b=J+EWiaevhZMw4yqKhMlEtuNOS7Jx7knX606mBix5lsjPK9LTM9vHArdQ1NDHvhNkDxnfkZzE tpnse1Ge/eJ7ICO+FMwNuiqgzAjv7HpkuuaRCJYIbnrEzDJp4Ttwumdt; 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: 02ec665d00de228c50c93ed6b5e4fc1a 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 Francois, I would vote 1) yes, 2) NA >From all I have seen on the list: a) It is ambiguous what one is asking for when SIPS is used, b) It is ambiguous what one will actually get. c) There is not enough polish to make this one shine. Better to define a new mechanism, perhaps as Dean suggests in the last paragraph below. This problem begs for a header/option tag based solution that makes clear what is requested, what is provided, and how success or failure is indicated. Mike > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, October 27, 2006 12:14 PM > To: Francois Audet > Cc: IETF SIP List > Subject: [Sip] Re: TLS meaning >=20 >=20 > On Oct 26, 2006, at 4:15 PM, Francois Audet wrote: >=20 > > Hi Dean, > > > > I'm OK with using other protocols (including DTLS and=20 > IPsec) to secure=20 > > signalling, but I don't see why you'd need to use SIPS for that. > > >=20 > That's a fair question. >=20 > I'd argue that the answer is "We would use sips: because that=20 > is the current mechanism by which and end user requests=20 > secure handling of signaling, indicating that if the other=20 > nodes cannot provide secure handling that the call is to fail=20 > rather than be handled insecurely" =20 > and "because it is important that users be able to demand=20 > this distinct handling model". >=20 > I suppose we could replace this with an option-tag in Require=20 > and Proxy-Require, and that if we did, we could just deprecate sips: =20 > completely. Now that I think of it this way, this might be a=20 > much better general mechanism anyhow, much closer to our=20 > usual negotiation model. >=20 > -- > Dean >=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 Oct 27 15:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXbM-00085Y-30; Fri, 27 Oct 2006 15:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXbK-00085T-LM for sip@ietf.org; Fri, 27 Oct 2006 15:42:46 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXbJ-00071m-93 for sip@ietf.org; Fri, 27 Oct 2006 15:42:46 -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 k9RJgfq18496; Fri, 27 Oct 2006 15:42:41 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 14:42:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DBCD3DA@zrc2hxm0.corp.nortel.com> In-Reply-To: <06c201c6f9f5$cc6a9a80$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb587N4UiCXaKedQKGSev8E7pQ42gAAVegQAAK+3cA= From: "Francois Audet" To: "Brian Rosen" , "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: "Joel M. Halpern" , 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 Right: this is exactly my position too.=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, October 27, 2006 11:29 AM > To: 'Paul Kyzivat'; 'Dean Willis' > Cc: 'Joel M. Halpern'; 'IETF SIP List' > Subject: RE: [Sip] RE: TLS meaning >=20 > I think that is some new mechanism, that needs a lot of work,=20 > and it's not sips. It has value, but I don't think we know=20 > how to do that. I think we could engineer a solution,=20 > although probably not real soon. >=20 > I would think you describe some set of properties you=20 > require, have some way to "vet" that a particular mechanism=20 > meets those properties, and then each hop can select among=20 > the available vetted mechanisms to meet the desired properties. =20 >=20 > I don't think agreeing on a suitable set of properties will=20 > be easy, and I don't think agreeing on how various tools we=20 > have map into those properties will be easy, but I think it=20 > may be possible. >=20 > I would give that mechanism a new name, and it may be worthy=20 > of its own work group. In the mean time sips =3D TLS (or DTLS)=20 > on every hop is of value, and easily specified. >=20 > Brian >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, October 27, 2006 2:12 PM > > To: Dean Willis > > Cc: Joel M. Halpern; 'IETF SIP List' > > Subject: Re: [Sip] RE: TLS meaning > >=20 > > OK, I know I am not sufficiently competent on security matters to=20 > > comment here. Nevertheless I will try: > >=20 > > It seems to me that if we are to have SIPS, then rather=20 > than tying it=20 > > to TLS or (D)TLS, or just defining it as "some security=20 > mechanism", it=20 > > ought to be tied to an extensible list of security=20 > mechanisms, with an=20 > > IANA registry and a procedure for approving new ones. We can argue=20 > > over the criteria that a new one must meet to qualify, but we won't=20 > > have restricted how many answers there are. > >=20 > > Paul > >=20 > > Dean Willis wrote: > > > > > > On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > > > > > >> Dean Willis writes: > > >>> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > > >>>> Well, I do. The security (authentication) properties=20 > of IPsec are=20 > > >>>> rather different then those of TLS. And why just say=20 > IPsec is OK.=20 > > >>>> What about WEP? What Once you relax the meaning to=20 > "secure" then=20 > > >>>> it's more or ess meaningless. > > >>> > > >>> Would you want it to fail if DTLS/DCCP were used=20 > instead of TLS/TCP? > > >> > > >> No, I don't see a problem with that. It seems to me that (D)TLS=20 > > >> over any transport has basically the same security properties,=20 > > >> which is the relevant issue here. > > > > > > That's useful to know. It might be possible to persuade=20 > the UDP fans=20 > > > in mobile land to use DTLS. I'm hearing good things about=20 > DTLS from=20 > > > other folks who have played with it on small systems. > > > > > > And I can clearly see that a blanket policy that would=20 > accept WEP as=20 > > > "Secured" would be bad. > > > > > > But please help us understand what's different about=20 > IPSEC usage in=20 > > > the IMS sense. > > > > > > IMS has a persistent IPSEC SA established between the=20 > edge proxy and=20 > > > the UA. Authentication is accomplished using the SIM as a token=20 > > > generator, and the crypto is one of the usual mechanisms (keep in=20 > > > mind TLS still allows plain small-key DES, which isn't all that=20 > > > strong). The applications are constructed so that the SIP=20 > function=20 > > > is aware of the SA and that it is connected to an=20 > authenticated party. > > > > > > What is different about the security properties here from TLS in=20 > > > outbound in such a way that it makes a difference to the SIP user? > > > > > > -- > > > Dean > > > > > > > > > _______________________________________________ > > > 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 From sip-bounces@ietf.org Fri Oct 27 15:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXiw-0005GW-0z; Fri, 27 Oct 2006 15:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXiq-00055G-Ls for sip@ietf.org; Fri, 27 Oct 2006 15:50: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 1GdXip-0000vT-CN for sip@ietf.org; Fri, 27 Oct 2006 15:50:32 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 12:50:31 -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 k9RJoUEf002604; Fri, 27 Oct 2006 12:50:30 -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 k9RJoUAo001581; Fri, 27 Oct 2006 12:50:30 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn5-519.cisco.com [10.21.90.7]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RJbunA020152; Fri, 27 Oct 2006 12:37:56 -0700 Message-ID: <45426305.6060904@cisco.com> Date: Fri, 27 Oct 2006 12:50:29 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> <86iri5n3cz.fsf@raman.networkresonance.com> In-Reply-To: <86iri5n3cz.fsf@raman.networkresonance.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=1838; t=1161978630; x=1162842630; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=guw1VHNxoHib8OIeqYUGbj2ANZTYvSAwwZz77SLFOIyD6gzRfv6fpBdG1r8W7uPqhREg7/59 dHq7pyWp18om0BRB+6EPoVjO16K7H04yD3D4XIqE7KEgkv1LxOT7os+R; X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Eric Rescorla wrote: >Michael Thomas writes: > > > >>This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism. >> >> > >Which is what SIPS is: a hopwise mechanism with a requirement >that each hop do the same thing. > > No. TLS is a hopwise mechanism. SIPS is a hopwise mechanism mated to transitive trust. They are not even remotely the same. They have *vastly* different security properties. >>>, and since it's something that we already know how to do, >>>I consider it worth doing while we figure out how to deploy >>>the better stuff. >>> >>> >>> >>Well, we manifestly do *not* know how to even do SIPS, hence our still >>talking >>about it 5 years out. >> >> > >No, I don't agree with that. I think we got it wrong the first >time but have a fairly good understanding of how to do it now. > > ^^ There's a missing pronoun here. If it was an implicit we, it must be a royal we because there seems to be a lot of people who don't understand what it's intended to do, let alone how to fix it. > > > >>Instead of trying yet again to polish this turd, >>why don't we... >>you know... look for some better stuff? >> >> > >Go ahead and suggest something. All I see you doing now is complaining. > > Golly, I tried to that about 5 years ago and what we got instead is SIPS at the last minute with little if any consensus. And lo and beyond, 5 years later we have a dysfunctional piece of protocol with little consensus and even less agreement on what should be done. So pardon me if I'm not biting on the chomp when the people who brought this to us still insist there's nothing wrong, and are in the position to make empty jestures as rhetorical devices. 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 Oct 27 16:00:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXqo-0004Em-T8; Fri, 27 Oct 2006 15:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXqm-00047i-4l for sip@ietf.org; Fri, 27 Oct 2006 15:58:44 -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 1GdXqL-0003Vb-Ds for sip@ietf.org; Fri, 27 Oct 2006 15:58:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2006 12:58:17 -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 k9RJwGnf006754; Fri, 27 Oct 2006 12:58:16 -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 k9RJwGin029377; Fri, 27 Oct 2006 12:58:16 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn5-519.cisco.com [10.21.90.7]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RJjg6J020333; Fri, 27 Oct 2006 12:45:42 -0700 Message-ID: <454264D7.3030702@cisco.com> Date: Fri, 27 Oct 2006 12:58:15 -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: Brian Rosen Subject: Re: [Sip] RE: TLS meaning References: <06c201c6f9f5$cc6a9a80$640fa8c0@cis.neustar.com> In-Reply-To: <06c201c6f9f5$cc6a9a80$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; 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=680; t=1161979096; x=1162843096; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=qsDAhNkPLleYWBlp+oeokKF9j2err+0etoyrZYME4vN8UmpyHcqBifowTr0ESuRYHdzaudwd t9dLWn3Q82furSSJS6j2DMN4t/r08FcRaRnt9rHKU/sHacdYvD8OFFLG; X-Spam-Score: 1.8 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Joel M. Halpern'" , '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 Brian Rosen wrote: >I would give that mechanism a new name, and it may be worthy of its own work >group. In the mean time sips = TLS (or DTLS) on every hop is of value, and >easily specified. > > Why should it be taken as a given the DTLS has the same properties as TLS? That is far from clear, not least of which is that DTLS is brand spanking new vs. the years and years of experience had with TLS. Extending SIPS to DTLS sustantially weakens the argument about why other protocols are not adequate. IPsec, for example, has way more water under the bridge, and there's a lot institutional knowledge about its properties, warts and all. 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 Oct 27 16:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXvI-0000jS-3O; Fri, 27 Oct 2006 16:03:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXvG-0000jH-QM for sip@ietf.org; Fri, 27 Oct 2006 16:03:22 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXuu-0004ko-Fe for sip@ietf.org; Fri, 27 Oct 2006 16:03:22 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7FC7E1E8C28; Fri, 27 Oct 2006 13:02:59 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 13:02:59 -0700 In-Reply-To: <45425D3C.3010308@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 12:25:48 -0700") Message-ID: <86zmbhle6k.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: 50a516d93fd399dc60588708fd9a3002 Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: > >>"Joel M. Halpern" writes: >> >> >> >>>So let me ask a question. Maybe a stupid question. >>>You are sending a SIP invite to someone. You want it secured. Let's >>>suppose you want it secured end to end. Let's even suppose that if it >>>is not secured end to end you want it ti fail. So you specify SIPS in >>>accordance with your definition. >>> >>>Do you really want that call to fail because two of the proxies in the >>>path are using IPSec instead of TLS? >>> >>> >> >>Well, I do. The security (authentication) properties of IPsec are rather >>different then those of TLS. And why just say IPsec is OK. What about >> WEP? What Once you relax the meaning to "secure" then it's more or >> ess meaningless. >> >> >> > This is true even with TLS: you can have wildly different security > properties between > two TLS sessions. Absolutely true. But the authentication properties (once you profile the cert validation rules as done in 3261) do not vary very much. > SIPS happily paves over those differences with the > in context > meaningless word "secure". > > Let's put it this way: if you were charged with determining whether a > system was > adequately defended would SIPS *alone* tell you anything useful about > its worthiness > to withstand attacks? I claim not. That's pretty different than HTTPS. I don't agree that it wouldn't tell you anything 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 Oct 27 16:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXwz-0002jt-DC; Fri, 27 Oct 2006 16:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXwy-0002fs-4O for sip@ietf.org; Fri, 27 Oct 2006 16:05:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXwZ-0005N3-OX for sip@ietf.org; Fri, 27 Oct 2006 16:05:08 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 13:04:43 -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 k9RK4h0X015440; Fri, 27 Oct 2006 13:04:43 -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 k9RK4hW4025207; Fri, 27 Oct 2006 13:04:43 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn5-519.cisco.com [10.21.90.7]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RJq37U020472; Fri, 27 Oct 2006 12:52:05 -0700 Message-ID: <45426655.6010602@cisco.com> Date: Fri, 27 Oct 2006 13:04:37 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> In-Reply-To: <86zmbhle6k.fsf@raman.networkresonance.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=1742; t=1161979483; x=1162843483; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=ZDL0r7wRfK5dONHlWmJmQfyQL3fZn/ZbUl1sCeQZDoaBsM16EksdkOGba39KK19sPcM3ivpX jC081E2jF8mS47gMoHR/bnbGkHmWPsbKijDbue4qNLxdlf6DEJ+nIRwD; X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Joel M. Halpern" , '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 Eric Rescorla wrote: >Michael Thomas writes: > > > >>Eric Rescorla wrote: >> >> >> >>>"Joel M. Halpern" writes: >>> >>> >>> >>> >>> >>>>So let me ask a question. Maybe a stupid question. >>>>You are sending a SIP invite to someone. You want it secured. Let's >>>>suppose you want it secured end to end. Let's even suppose that if it >>>>is not secured end to end you want it ti fail. So you specify SIPS in >>>>accordance with your definition. >>>> >>>>Do you really want that call to fail because two of the proxies in the >>>>path are using IPSec instead of TLS? >>>> >>>> >>>> >>>> >>>Well, I do. The security (authentication) properties of IPsec are rather >>>different then those of TLS. And why just say IPsec is OK. What about >>>WEP? What Once you relax the meaning to "secure" then it's more or >>>ess meaningless. >>> >>> >>> >>> >>> >>This is true even with TLS: you can have wildly different security >>properties between >>two TLS sessions. >> >> > >Absolutely true. But the authentication properties (once you >profile the cert validation rules as done in 3261) do not vary >very much. > > > > >>SIPS happily paves over those differences with the >>in context >>meaningless word "secure". >> >>Let's put it this way: if you were charged with determining whether a >>system was >>adequately defended would SIPS *alone* tell you anything useful about >>its worthiness >>to withstand attacks? I claim not. That's pretty different than HTTPS. >> >> > >I don't agree that it wouldn't tell you anything useful. > > Care to elucidate? What does it tell you by _itself_? 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 Oct 27 16:09:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXyx-0004WU-Jp; Fri, 27 Oct 2006 16:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXyv-0004Ts-PN for sip@ietf.org; Fri, 27 Oct 2006 16:07:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdXyu-00061A-Gg for sip@ietf.org; Fri, 27 Oct 2006 16:07:09 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 13:07:08 -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 k9RK77aZ015535; Fri, 27 Oct 2006 13:07:07 -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 k9RK77Ao012987; Fri, 27 Oct 2006 13:07:07 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn5-519.cisco.com [10.21.90.7]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RJsXrO020520; Fri, 27 Oct 2006 12:54:33 -0700 Message-ID: <454266EB.5040105@cisco.com> Date: Fri, 27 Oct 2006 13:07:07 -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: Paul Kyzivat Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <45424A0B.8010903@cisco.com> In-Reply-To: <45424A0B.8010903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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=773; t=1161979627; x=1162843627; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=nBkk8K2DEXu+1IQF2w0o4cROLMF2zgq93jMhMvjiN1nQ43XKgN2LaE5nYbD8FMOOrUJQ6n2G whUZ7etC4mT23PQbmKc/I9VILUhVSVMlSvPd+nE37p2lYOzzm4QGGYF2; X-Spam-Score: 1.8 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Joel M. Halpern" , '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 Paul Kyzivat wrote: > In general, I want "best effort security", by which I mean I want a > secure call if I can get it, else I want an insecure call. But I want > to know for sure which I got, so I can make a decision about how I use > it. The base problem here is that people are trying to shoehorn a BCP into a normative protocol. For a BCP, it would be perfectly reasonable to say "if you get TLS in, send TLS out". Good net citizen, have a cookie. You get all of the same assurances as SIPS (which is to say, none), but don't drag in all of this pretzel logic about what should happen when you have a WUP (worst uncommon practice) in the path, and all of the unintended conflation of SIPS with HTTPS by the unwashed masses. 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 Oct 27 16:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdY84-0003hu-Vs; Fri, 27 Oct 2006 16:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdY84-0003hk-8A for sip@ietf.org; Fri, 27 Oct 2006 16:16:36 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdY82-0008AF-T0 for sip@ietf.org; Fri, 27 Oct 2006 16:16:36 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 702A71E8C28; Fri, 27 Oct 2006 13:16:34 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> <86iri5n3cz.fsf@raman.networkresonance.com> <45426305.6060904@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 13:16:34 -0700 In-Reply-To: <45426305.6060904@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 12:50:29 -0700") Message-ID: <86u01pldjx.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: 0a7aa2e6e558383d84476dc338324fab Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Michael Thomas writes: > Eric Rescorla wrote: > >>Michael Thomas writes: >> >> >> >>>This is a strawman. Nobody is objecting to using TLS as a hopwise mechanism. >>> >>> >> >>Which is what SIPS is: a hopwise mechanism with a requirement >>that each hop do the same thing. >> >> > > No. TLS is a hopwise mechanism. SIPS is a hopwise mechanism mated to > transitive trust. They are not even remotely the same. They have *vastly* > different security properties. Sure. The message that started this chain read: , and I'm certainly in favor of of end-to-end security mechanisms. However, I don't think that that means that SIP over TLS has minimal value So, feel free to substitute "SIPS" for "SIP over TLS" in the above sentence. > There's a missing pronoun here. If it was an implicit we, it must > be a royal we > because there seems to be a lot of people who don't understand > what it's intended to > do, let alone how to fix it. Sure, me plus some other people. > Golly, I tried to that about 5 years ago and what we got instead is > SIPS at the > last minute with little if any consensus. And lo and beyond, 5 years > later we > have a dysfunctional piece of protocol with little consensus and even > less agreement > on what should be done. So pardon me if I'm not biting on the chomp when the > people who brought this to us still insist there's nothing wrong, and > are in the > position to make empty jestures as rhetorical devices. Funny, what I remember about five years ago was that you were mostly doing the same kind of complaining you're doing now, so pardon me if I don't consider the fact that you're unhappy with SIPS to be a total showstopper. -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 Oct 27 16:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYDi-0006h4-Ol; Fri, 27 Oct 2006 16:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYDh-0006cM-4d for sip@ietf.org; Fri, 27 Oct 2006 16:22:25 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYDf-0001F4-Qi for sip@ietf.org; Fri, 27 Oct 2006 16:22:25 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 50C411E8C28; Fri, 27 Oct 2006 13:22:23 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <06c201c6f9f5$cc6a9a80$640fa8c0@cis.neustar.com> <454264D7.3030702@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 13:22:23 -0700 In-Reply-To: <454264D7.3030702@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 12:58:15 -0700") Message-ID: <86k62llda8.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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "'Joel M. Halpern'" , 'IETF SIP List' , 'Paul Kyzivat' , '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 Michael Thomas writes: > Brian Rosen wrote: > >>I would give that mechanism a new name, and it may be worthy of its own work >>group. In the mean time sips = TLS (or DTLS) on every hop is of value, and >>easily specified. >> >> > Why should it be taken as a given the DTLS has the same properties as > TLS? > That > is far from clear, not least of which is that DTLS is brand spanking > new vs. the > years and years of experience had with TLS. It shouldn't be taken as a given, it should be concluded from studying the two protocols. There is an extended discussion of this point in the DTLS paper (not the RFC). > Extending SIPS to DTLS > sustantially > weakens the argument about why other protocols are not > adequate. IPsec, for example, > has way more water under the bridge, and there's a lot institutional > knowledge about > its properties, warts and all. The issue isn't primarily about security level, but rather about the security guarantees and model it's intended to implement. The authentication, key management and dataflow model of DTLS matches TLS and that's the kind of thing I worry about getting right at least as much as the crypto. -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 Oct 27 16:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYG2-00061Z-Qm; Fri, 27 Oct 2006 16:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYG0-0005wQ-Lg for sip@ietf.org; Fri, 27 Oct 2006 16:24:48 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYFy-0001uz-2N for sip@ietf.org; Fri, 27 Oct 2006 16:24:48 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A01491E8C28; Fri, 27 Oct 2006 13:24:45 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 13:24:45 -0700 In-Reply-To: <45426655.6010602@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 13:04:37 -0700") Message-ID: <86fyd9ld6a.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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: >> > Care to elucidate? What does it tell you by _itself_? Sure, it allows you to verify that you're talking to the correct next person and that if they also behave as they are required to, there will be a secure (minimally authenticated) channel between you and the final proxy. If SIPS were revised to remove the last hop exception then you could write "UAS" for "final proxy". -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 Oct 27 16:26:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYGE-0006Sm-Ij; Fri, 27 Oct 2006 16:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYGD-0006SY-9U for sip@ietf.org; Fri, 27 Oct 2006 16:25:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYGB-0001xG-5i for sip@ietf.org; Fri, 27 Oct 2006 16:25:01 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 13:24:59 -0700 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 k9RKOwhO011578; Fri, 27 Oct 2006 13:24:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9RKOwOV019740; Fri, 27 Oct 2006 13:24:58 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Oct 2006 13:24:42 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 13:24:41 -0700 Message-ID: <45426B08.4040901@cisco.com> Date: Fri, 27 Oct 2006 16:24: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: Rohan Mahy Subject: Re: [Sip] Updated GRUU spec - big changes References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> In-Reply-To: <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 20:24:42.0140 (UTC) FILETIME=[EF313DC0:01C6FA05] DKIM-Signature: a=rsa-sha1; q=dns; l=3296; t=1161980698; x=1162844698; 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]=20Updated=20GRUU=20spec=20-=20big=20changes; X=v=3Dcisco.com=3B=20h=3D9J1BlY1qWrrKT9rSlWu3ddnh4Nc=3D; b=gWxvdr1w7a6CgIrFhIGPoD/gIVhyr8gDPG7N4V/RvwK8esZlZFwhjZ7cb682RpPHYF7cXyqC 9WTi+hQjXzXb02oLX/yBgn1dX5f9KLYhgRoC383vIPixLORIOJPVuTXB; 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: 31247fb3be228bb596db9127becad0bc Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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. Rohan Mahy wrote: > Hi Eric, > > > On 10/26/06, Eric Rescorla wrote: > >> I always have trouble learning from examples, so I hope you'll >> forgive me if I've misunderstood. > > > Of course. > >> It seems to me that there are three key points to this proposal: >> >> 1. The "limited-use" GRUU is tied to the long-term GRUU rather than >> to an AOR. > > yes. one advantage IMO is that the lifetime of the limited-use GRUU > is unrelated to the stability of the underlying connection. I can > fetch a limited use GRUU, go into a tunnel, come out with a different > IP address, and reregister my instance without having to refresh any > of my limited-use GRUUs. I'm confused. In the current -11 mechanism, the same thing is true; if you go into a tunnel and you get a new IP address when you come out, you register with a new IP address and the same instance ID. All existing gruu continue to work. There are no extra registrations. However your mechanism has the major disadvantage of requiring an extra REGISTER to allocate a new temporary gruu prior to an anonymous call. That extra registration is a big deal for many systems. COnsider the craziness IMS goes through when a register happens. > >> 2. The client explicitly controls limited-use GRUUs rather than >> having them issued by the server as an automatic side effect > > yes. if I want a 5 minute validity GRUU or a week long validity GRUU > I can get one and refresh (or not) independently. WIth whats in -11 the idea is that the lifetime is the length of your registration, and that normally you are not wanting to kill the validity of the temporary gruu - thats not a privacy issue, its a spam issue. If you do want to kill it, you can use the consent framework for example to do that. But thats a secondary need. > > I can also get a GRUU that is limited use but still tied to my AOR. > Possibly useful for allowing that pesky salesperson to bypass my call > screening for a day or two about something important. > > As for load, the UA only generates load on the server when it needs > something new. If the UA doesn't need any private GRUU, the server > doesn't need to generate one. If the UA wants a unique GRUU per-call, > the registrar does not need to do a full outbound-style registration > (making and saving flow tokens, etc.) In -11 there is no extra messaging load on the server beyond regular registration handling, and it gives the client a near infinite suppy of unlinkable addresses, so that a user can use a different one in each call without any additional signaling. > >> 3. The client proposes the limited-use GRUU, not the server. > > no, the server still forms the actual lmited-use GRUU. THen I'm confused like ekr. I thought your proposal had the contact of the second registration containing the temporary 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 Fri Oct 27 16:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYHV-0007vu-QW; Fri, 27 Oct 2006 16:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYHU-0007vh-9B for sip@ietf.org; Fri, 27 Oct 2006 16:26:20 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYHS-0002Es-SP for sip@ietf.org; Fri, 27 Oct 2006 16:26:20 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 833FB1E8C28; Fri, 27 Oct 2006 13:26:18 -0700 (PDT) To: "Rohan Mahy" Subject: Re: [Sip] Updated GRUU spec - big changes References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 13:26:18 -0700 In-Reply-To: <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> (Rohan Mahy's message of "Fri, 27 Oct 2006 11:50:10 -0700") Message-ID: <86ejstld3p.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: IETF SIP List , "Drage, Keith \(Keith\)" 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 "Rohan Mahy" writes: > Hi Eric, > > > On 10/26/06, Eric Rescorla wrote: >> I always have trouble learning from examples, so I hope you'll >> forgive me if I've misunderstood. > > Of course. > >> It seems to me that there are three key points to this proposal: >> >> 1. The "limited-use" GRUU is tied to the long-term GRUU rather than >> to an AOR. > yes. one advantage IMO is that the lifetime of the limited-use GRUU > is unrelated to the stability of the underlying connection. I can > fetch a limited use GRUU, go into a tunnel, come out with a different > IP address, and reregister my instance without having to refresh any > of my limited-use GRUUs. Right. >> 2. The client explicitly controls limited-use GRUUs rather than >> having them issued by the server as an automatic side effect > yes. if I want a 5 minute validity GRUU or a week long validity GRUU > I can get one and refresh (or not) independently. > > I can also get a GRUU that is limited use but still tied to my AOR. > Possibly useful for allowing that pesky salesperson to bypass my call > screening for a day or two about something important. > > As for load, the UA only generates load on the server when it needs > something new. If the UA doesn't need any private GRUU, the server > doesn't need to generate one. If the UA wants a unique GRUU per-call, > the registrar does not need to do a full outbound-style registration > (making and saving flow tokens, etc.) I'm not an expert on SIP stacks, so maybe I'm missing something here, but doesn't JDR's new draft have a lightweight way to fetch a new anonymous GRUU? >> 3. The client proposes the limited-use GRUU, not the server. > no, the server still forms the actual lmited-use GRUU. Can you explain how that works again? I didn't quite get it from your example. Thanks, -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 Oct 27 16:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYP2-0002BA-Ow; Fri, 27 Oct 2006 16:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYP1-0002Az-WA for sip@ietf.org; Fri, 27 Oct 2006 16:34:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYP0-00041k-HF for sip@ietf.org; Fri, 27 Oct 2006 16:34:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2006 16:34:07 -0400 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 k9RKY6Ac007584; Fri, 27 Oct 2006 16:34:06 -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 k9RKY5DM001992; Fri, 27 Oct 2006 16:34:05 -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); Fri, 27 Oct 2006 16:34:05 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 16:34:04 -0400 Message-ID: <45426D3C.4050309@cisco.com> Date: Fri, 27 Oct 2006 16:34:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DBCD3DA@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DBCD3DA@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 20:34:05.0025 (UTC) FILETIME=[3EB2AD10:01C6FA07] DKIM-Signature: a=rsa-sha1; q=dns; l=5525; t=1161981246; x=1162845246; 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]=20RE=3A=20TLS=20meaning |To:Francois=20Audet=20; X=v=3Dcisco.com=3B=20h=3D8T2qLW38YZ2FX38zFN0RkJYv1P0=3D; b=Seueem+GU+45m4W9D30l/mRnfggVup5gPWZ6UAzEW96bz3lpBYOJb6khqaUxC6MAOv59L0Lt LxTSBhFEy3WhpnVBVZbTKCTOFxyHKLNB/ohfeUsJYgDsmfwgJlcMKchh; 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: 68ba2b07ef271dba6ee42a93832cfa4c Cc: "Joel M. Halpern" , 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 Note that my comment and Brian's initial one on the same subject were independently and simultaneously created. As soon as I saw Brian's comment I knew he would be replying back to me. I don't dispute that making the necessary specifications will be hard. I don't know if it would be useful to attach the SIPS name to this new thing or not. It may be that some other way (e.g. Proxy-Require) would be better. Or maybe a scheme name, SIPS or something else, would really be good for it. But I'm so far not convinced that an all-TLS-based SIPS actually delivers anything that has a practical use. Paul Francois Audet wrote: > Right: this is exactly my position too. > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Friday, October 27, 2006 11:29 AM >> To: 'Paul Kyzivat'; 'Dean Willis' >> Cc: 'Joel M. Halpern'; 'IETF SIP List' >> Subject: RE: [Sip] RE: TLS meaning >> >> I think that is some new mechanism, that needs a lot of work, >> and it's not sips. It has value, but I don't think we know >> how to do that. I think we could engineer a solution, >> although probably not real soon. >> >> I would think you describe some set of properties you >> require, have some way to "vet" that a particular mechanism >> meets those properties, and then each hop can select among >> the available vetted mechanisms to meet the desired properties. >> >> I don't think agreeing on a suitable set of properties will >> be easy, and I don't think agreeing on how various tools we >> have map into those properties will be easy, but I think it >> may be possible. >> >> I would give that mechanism a new name, and it may be worthy >> of its own work group. In the mean time sips = TLS (or DTLS) >> on every hop is of value, and easily specified. >> >> Brian >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Friday, October 27, 2006 2:12 PM >>> To: Dean Willis >>> Cc: Joel M. Halpern; 'IETF SIP List' >>> Subject: Re: [Sip] RE: TLS meaning >>> >>> OK, I know I am not sufficiently competent on security matters to >>> comment here. Nevertheless I will try: >>> >>> It seems to me that if we are to have SIPS, then rather >> than tying it >>> to TLS or (D)TLS, or just defining it as "some security >> mechanism", it >>> ought to be tied to an extensible list of security >> mechanisms, with an >>> IANA registry and a procedure for approving new ones. We can argue >>> over the criteria that a new one must meet to qualify, but we won't >>> have restricted how many answers there are. >>> >>> Paul >>> >>> Dean Willis wrote: >>>> On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: >>>> >>>>> Dean Willis writes: >>>>>> On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: >>>>>>> Well, I do. The security (authentication) properties >> of IPsec are >>>>>>> rather different then those of TLS. And why just say >> IPsec is OK. >>>>>>> What about WEP? What Once you relax the meaning to >> "secure" then >>>>>>> it's more or ess meaningless. >>>>>> Would you want it to fail if DTLS/DCCP were used >> instead of TLS/TCP? >>>>> No, I don't see a problem with that. It seems to me that (D)TLS >>>>> over any transport has basically the same security properties, >>>>> which is the relevant issue here. >>>> That's useful to know. It might be possible to persuade >> the UDP fans >>>> in mobile land to use DTLS. I'm hearing good things about >> DTLS from >>>> other folks who have played with it on small systems. >>>> >>>> And I can clearly see that a blanket policy that would >> accept WEP as >>>> "Secured" would be bad. >>>> >>>> But please help us understand what's different about >> IPSEC usage in >>>> the IMS sense. >>>> >>>> IMS has a persistent IPSEC SA established between the >> edge proxy and >>>> the UA. Authentication is accomplished using the SIM as a token >>>> generator, and the crypto is one of the usual mechanisms (keep in >>>> mind TLS still allows plain small-key DES, which isn't all that >>>> strong). The applications are constructed so that the SIP >> function >>>> is aware of the SA and that it is connected to an >> authenticated party. >>>> What is different about the security properties here from TLS in >>>> outbound in such a way that it makes a difference to the SIP 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 >>>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 Oct 27 16:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYhZ-0002dx-2S; Fri, 27 Oct 2006 16:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYhX-0002ds-Hf for sip@ietf.org; Fri, 27 Oct 2006 16:53:15 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYhW-0008BL-5S for sip@ietf.org; Fri, 27 Oct 2006 16:53:15 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9RKrDmt022563 for ; Fri, 27 Oct 2006 14:53:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 14:53:12 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated SIP Certificate Authentication Requirements Draft Thread-Index: Acb6Cenn6kijv6GGT+ebl8yvYoIAZw== From: "Steve Dotson" To: "IETF SIP List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Sip] Updated SIP Certificate Authentication Requirements Draft X-BeenThere: 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="===============0714836738==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0714836738== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FA09.EA780D46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FA09.EA780D46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email is to request feedback regarding the SIP certificate authentication requirements draft http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-01 .txt . >From the abstract: 'This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). It is intended that potential solutions specifying certificate authentication within SIP will use these requirements as guidelines. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios.' As a note, the I-D has been updated based on various offline comments received at IETF#66 regarding draft-00. Comments and thoughts are appreciated. =20 Thanks, =20 Steve. =20 ------_=_NextPart_001_01C6FA09.EA780D46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This email is to request feedback regarding the SIP certificate=20 authentication requirements draft http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate= -auth-01.txt .

From the abstract:

'This document defines requirements for adding certificate = authentication to=2From sip-bounces@ietf.org Fri Oct 27 16:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYhZ-0002dx-2S; Fri, 27 Oct 2006 16:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYhX-0002ds-Hf for sip@ietf.org; Fri, 27 Oct 2006 16:53:15 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYhW-0008BL-5S for sip@ietf.org; Fri, 27 Oct 2006 16:53:15 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9RKrDmt022563 for ; Fri, 27 Oct 2006 14:53:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 14:53:12 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated SIP Certificate Authentication Requirements Draft Thread-Index: Acb6Cenn6kijv6GGT+ebl8yvYoIAZw== From: "Steve Dotson" To: "IETF SIP List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [Sip] Updated SIP Certificate Authentication Requirements Draft X-BeenThere: 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="===============0714836738==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0714836738== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FA09.EA780D46" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FA09.EA780D46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email is to request feedback regarding the SIP certificate authentication requirements draft http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-01 .txt . >From the abstract: 'This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). It is intended that potential solutions specifying certificate authentication within SIP will use these requirements as guidelines. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios.' As a note, the I-D has been updated based on various offline comments received at IETF#66 regarding draft-00. Comments and thoughts are appreciated. =20 Thanks, =20 Steve. =20 ------_=_NextPart_001_01C6FA09.EA780D46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This email is to request feedback regarding the SIP certificate=20 authentication requirements draft http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate= -auth-01.txt .

From the abstract:

'This document defines requirements for adding certificate = authentication to=20 the Session Initiation Protocol (SIP). It is intended that potential = solutions=20 specifying certificate authentication within SIP will use these = requirements as=20 guidelines. Supporting certificate authentication in SIP would provide = strong=20 authentication and increase the types of possible deployment = scenarios.'

As a note, the I-D has been updated based on various offline comments = received at IETF#66 regarding draft-00.

Comments and thoughts are appreciated.

 

Thanks,

 

Steve.

 

------_=_NextPart_001_01C6FA09.EA780D46-- --===============0714836738== 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 --===============0714836738==-- From sip-bounces@ietf.org Fri Oct 27 16:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYiU-0002w8-KZ; Fri, 27 Oct 2006 16:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYiT-0002w2-2G for sip@ietf.org; Fri, 27 Oct 2006 16:54:13 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYiR-00007F-Or for sip@ietf.org; Fri, 27 Oct 2006 16:54:13 -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 k9RKs7P23299; Fri, 27 Oct 2006 16:54:07 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 15:54:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> In-Reply-To: <45426D3C.4050309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6B0Jg9fVC0RkJRtm6cn9NR4AinAAAb1XA From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Joel M. Halpern" , 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 The practical use is to be able to deploy hop-by-hop TLS-based SIP signalling (using transitive trust), with the current RFC 3261=20 complemented with the explanation of my draft, in the SHORT TERM. I.e., without waiting for SIP to develop the next protocol that allows for0 the Session Initiation Protocol (SIP). It is intended that potential = solutions=20 specifying certificate authentication within SIP will use these = requirements as=20 guidelines. Supporting certificate authentication in SIP would provide = strong=20 authentication and increase the types of possible deployment = scenarios.'

As a note, the I-D has been updated based on various offline comments = received at IETF#66 regarding draft-00.

Comments and thoughts are appreciated.

 

Thanks,

 

Steve.

 

------_=_NextPart_001_01C6FA09.EA780D46-- --===============0714836738== 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 --===============0714836738==-- From sip-bounces@ietf.org Fri Oct 27 16:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYiU-0002w8-KZ; Fri, 27 Oct 2006 16:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYiT-0002w2-2G for sip@ietf.org; Fri, 27 Oct 2006 16:54:13 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYiR-00007F-Or for sip@ietf.org; Fri, 27 Oct 2006 16:54:13 -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 k9RKs7P23299; Fri, 27 Oct 2006 16:54:07 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 15:54:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> In-Reply-To: <45426D3C.4050309@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6B0Jg9fVC0RkJRtm6cn9NR4AinAAAb1XA From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Joel M. Halpern" , 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 The practical use is to be able to deploy hop-by-hop TLS-based SIP signalling (using transitive trust), with the current RFC 3261=20 complemented with the explanation of my draft, in the SHORT TERM. I.e., without waiting for SIP to develop the next protocol that allows for other alternative security mechanisms. You have to understand that people ARE implementing sips today because of market demand. They won't stop doing this because we promise them that a few years from now, we'll have something better. I'd much rather have implementations that follow our recommendations on that front, rather than have vastly different intrepretation of RFC 3261's SIPS. If we don't have practical guidelines for the current state of the art, that's exactly what will happen. I don't believe any of us is arguing that sips is the greatest thing since slice bread. I don't think any of us is arguing that it is unreasonable to use other protocols for securing SIP either (although there is a split of opinions on if that should be called sips or not). We are just saying that sips can relatively easily be made to work for=20 hop-by-hop TLS, in the short term. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 27, 2006 1:34 PM > To: Audet, Francois (SC100:3055) > Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Note that my comment and Brian's initial one on the same=20 > subject were independently and simultaneously created. As=20 > soon as I saw Brian's comment I knew he would be replying back to me. >=20 > I don't dispute that making the necessary specifications will=20 > be hard. I don't know if it would be useful to attach the=20 > SIPS name to this new thing or not. It may be that some other=20 > way (e.g. Proxy-Require) would be better. Or maybe a scheme=20 > name, SIPS or something else, would really be good for it. >=20 > But I'm so far not convinced that an all-TLS-based SIPS=20 > actually delivers anything that has a practical use. >=20 > 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 other alternative security mechanisms. You have to understand that people ARE implementing sips today because of market demand. They won't stop doing this because we promise them that a few years from now, we'll have something better. I'd much rather have implementations that follow our recommendations on that front, rather than have vastly different intrepretation of RFC 3261's SIPS. If we don't have practical guidelines for the current state of the art, that's exactly what will happen. I don't believe any of us is arguing that sips is the greatest thing since slice bread. I don't think any of us is arguing that it is unreasonable to use other protocols for securing SIP either (although there is a split of opinions on if that should be called sips or not). We are just saying that sips can relatively easily be made to work for=20 hop-by-hop TLS, in the short term. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 27, 2006 1:34 PM > To: Audet, Francois (SC100:3055) > Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Note that my comment and Brian's initial one on the same=20 > subject were independently and simultaneously created. As=20 > soon as I saw Brian's comment I knew he would be replying back to me. >=20 > I don't dispute that making the necessary specifications will=20 > be hard. I don't know if it would be useful to attach the=20 > SIPS name to this new thing or not. It may be that some other=20 > way (e.g. Proxy-Require) would be better. Or maybe a scheme=20 > name, SIPS or something else, would really be good for it. >=20 > But I'm so far not convinced that an all-TLS-based SIPS=20 > actually delivers anything that has a practical use. >=20 > 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 Oct 27 17:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZD4-0002AD-5y; Fri, 27 Oct 2006 17:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZD3-0002A3-2V for sip@ietf.org; Fri, 27 Oct 2006 17:25:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZD1-0007Tv-Py for sip@ietf.org; Fri, 27 Oct 2006 17:25:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 14:25:47 -0700 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 k9RLPlYP026509; Fri, 27 Oct 2006 14:25:47 -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 k9RLPlW4025896; Fri, 27 Oct 2006 14:25:47 -0700 (PDT) Received: from [10.7.1.115] (sjc-vpn6-642.cisco.com [10.21.122.130]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RLDCFp022267; Fri, 27 Oct 2006 14:13:12 -0700 Message-ID: <45427955.3010708@cisco.com> Date: Fri, 27 Oct 2006 14:25:41 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> <86fyd9ld6a.fsf@raman.networkresonance.com> In-Reply-To: <86fyd9ld6a.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=857; t=1161984347; x=1162848347; c=relaxed/simple; s=sjdkim3002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=mxM3lpT14MQYBZo++EPMu1QmP8PvKaieEsBkg2ejY25Zm/FNS2uA1iXxhW6MrTF7eO2Vf1mh 0FWZRn2/zUrb9rYuz1h7iRi53Jk9VU3lG35YaDlGQaXnOfDiH37eEh45; X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Joel M. Halpern" , '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 Eric Rescorla wrote: >Michael Thomas writes: > > >>Eric Rescorla wrote: >> >> >>Care to elucidate? What does it tell you by _itself_? >> >> > >Sure, it allows you to verify that you're talking to the correct >next person.... > This is correct, and just as easily accomplished by talking to a well known sip-over-tls port. > and that if they also behave as they are required >to, there will be a secure (minimally authenticated) channel >between you and the final proxy. If SIPS were revised to remove >the last hop exception then you could write "UAS" for "final >proxy". > > This is just a hope on the part of the UAC. In analyzing a system, I'd expect that you'd be more rigorous than vague and unverifyable hopes. In which case SIPS does not provide anything useful by itself. 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 Oct 27 17:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZaq-0007vm-95; Fri, 27 Oct 2006 17:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZao-0007vD-OD for sip@ietf.org; Fri, 27 Oct 2006 17:50:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZam-00033p-Dm for sip@ietf.org; Fri, 27 Oct 2006 17:50:22 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RKrnrF000682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 15:53:50 -0500 In-Reply-To: <45427955.3010708@cisco.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> <86fyd9ld6a.fsf@raman.networkresonance.com> <45427955.3010708@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92D09884-AC72-481E-AF33-A36C7F9F84FD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 16:50:17 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Joel M. Halpern" , '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 Oct 27, 2006, at 4:25 PM, Michael Thomas wrote: > >> and that if they also behave as they are required >> to, there will be a secure (minimally authenticated) channel >> between you and the final proxy. If SIPS were revised to remove >> the last hop exception then you could write "UAS" for "final >> proxy". >> > This is just a hope on the part of the UAC. In analyzing a system, > I'd expect that > you'd be more rigorous than vague and unverifyable hopes. In which > case SIPS > does not provide anything useful by itself. So what we have here is a security assurance that's equivalent to having your used car salesman (and you know where he lives) promise to provide service after the sale, as opposed to a sale where you have no such promise and are buying your goods out of the back of an unmarked van from some guy named Joe. It all comes down to "you trust the sed-car sales guy more (even though he MIGHT cheat you) because there's a chance you can come after him if the deal goes bad." While not rigorous, that's still a little better basis for trust than nothing at all. -- 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 Oct 27 17:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZZo-0007Ed-Vp; Fri, 27 Oct 2006 17:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZZo-0007EX-9B for sip@ietf.org; Fri, 27 Oct 2006 17:49:20 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZZm-0002kZ-Ul for sip@ietf.org; Fri, 27 Oct 2006 17:49:20 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1160A1E8C2C; Fri, 27 Oct 2006 14:49:12 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> <86fyd9ld6a.fsf@raman.networkresonance.com> <45427955.3010708@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 14:49:12 -0700 In-Reply-To: <45427955.3010708@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 14:25:41 -0700") Message-ID: <86wt6ljup3.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: 50a516d93fd399dc60588708fd9a3002 Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: > >>Michael Thomas writes: >> >> >>>Eric Rescorla wrote: >>> >>> >>>Care to elucidate? What does it tell you by _itself_? >>> >>> >> >>Sure, it allows you to verify that you're talking to the correct >>next person.... >> > > This is correct, and just as easily accomplished by talking to a well known > sip-over-tls port. Sure. >> and that if they also behave as they are required >>to, there will be a secure (minimally authenticated) channel >>between you and the final proxy. If SIPS were revised to remove >>the last hop exception then you could write "UAS" for "final >>proxy". >> >> > This is just a hope on the part of the UAC. In analyzing a system, I'd > expect that > you'd be more rigorous than vague and unverifyable hopes. In which case SIPS > does not provide anything useful by itself. If by "just a hope" you mean "the client can't enforce it" then sure, that's true. But that doesn't make it valueless, it simply means that the proxy is inside of your trust boundary. Sure, that's not as nice as having it not be inside of your trust boundary, but it's a tradeoff. Anyway, I think we've said all there is useful to say here. We all agree about what the behavior of SIPS is, you just happen to think it's not of value whereas I do. Continuing to reassert our opinions doesn't really buy us anything. -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 Oct 27 17:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZaq-0007vm-95; Fri, 27 Oct 2006 17:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZao-0007vD-OD for sip@ietf.org; Fri, 27 Oct 2006 17:50:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZam-00033p-Dm for sip@ietf.org; Fri, 27 Oct 2006 17:50:22 -0400 Received: from [192.168.1.101] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9RKrnrF000682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Oct 2006 15:53:50 -0500 In-Reply-To: <45427955.3010708@cisco.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> <86fyd9ld6a.fsf@raman.networkresonance.com> <45427955.3010708@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92D09884-AC72-481E-AF33-A36C7F9F84FD@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] RE: TLS meaning Date: Fri, 27 Oct 2006 16:50:17 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Joel M. Halpern" , '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 Oct 27, 2006, at 4:25 PM, Michael Thomas wrote: > >> and that if they also behave as they are required >> to, there will be a secure (minimally authenticated) channel >> between you and the final proxy. If SIPS were revised to remove >> the last hop exception then you could write "UAS" for "final >> proxy". >> > This is just a hope on the part of the UAC. In analyzing a system, > I'd expect that > you'd be more rigorous than vague and unverifyable hopes. In which > case SIPS > does not provide anything useful by itself. So what we have here is a security assurance that's equivalent to having your used car salesman (and you know where he lives) promise to provide service after the sale, as opposed to a sale where you have no such promise and are buying your goods out of the back of an unmarked van from some guy named Joe. It all comes down to "you trust the sed-car sales guy more (even though he MIGHT cheat you) because there's a chance you can come after him if the deal goes bad." While not rigorous, that's still a little better basis for trust than nothing at all. -- 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 Oct 27 17:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZZo-0007Ed-Vp; Fri, 27 Oct 2006 17:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZZo-0007EX-9B for sip@ietf.org; Fri, 27 Oct 2006 17:49:20 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZZm-0002kZ-Ul for sip@ietf.org; Fri, 27 Oct 2006 17:49:20 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1160A1E8C2C; Fri, 27 Oct 2006 14:49:12 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <45425D3C.3010308@cisco.com> <86zmbhle6k.fsf@raman.networkresonance.com> <45426655.6010602@cisco.com> <86fyd9ld6a.fsf@raman.networkresonance.com> <45427955.3010708@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 14:49:12 -0700 In-Reply-To: <45427955.3010708@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 14:25:41 -0700") Message-ID: <86wt6ljup3.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: 50a516d93fd399dc60588708fd9a3002 Cc: "Joel M. Halpern" , 'IETF SIP List' 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 Michael Thomas writes: > Eric Rescorla wrote: > >>Michael Thomas writes: >> >> >>>Eric Rescorla wrote: >>> >>> >>>Care to elucidate? What does it tell you by _itself_? >>> >>> >> >>Sure, it allows you to verify that you're talking to the correct >>next person.... >> > > This is correct, and just as easily accomplished by talking to a well known > sip-over-tls port. Sure. >> and that if they also behave as they are required >>to, there will be a secure (minimally authenticated) channel >>between you and the final proxy. If SIPS were revised to remove >>the last hop exception then you could write "UAS" for "final >>proxy". >> >> > This is just a hope on the part of the UAC. In analyzing a system, I'd > expect that > you'd be more rigorous than vague and unverifyable hopes. In which case SIPS > does not provide anything useful by itself. If by "just a hope" you mean "the client can't enforce it" then sure, that's true. But that doesn't make it valueless, it simply means that the proxy is inside of your trust boundary. Sure, that's not as nice as having it not be inside of your trust boundary, but it's a tradeoff. Anyway, I think we've said all there is useful to say here. We all agree about what the behavior of SIPS is, you just happen to think it's not of value whereas I do. Continuing to reassert our opinions doesn't really buy us anything. -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 Oct 27 18:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gda8M-0006S9-Az; Fri, 27 Oct 2006 18:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gda8J-0006Qf-P8 for sip@ietf.org; Fri, 27 Oct 2006 18:24:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gda8H-0005kk-Cc for sip@ietf.org; Fri, 27 Oct 2006 18:24:59 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 15:24:57 -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 k9RMOukO020245; Fri, 27 Oct 2006 15:24:56 -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 k9RMOubF001250; Fri, 27 Oct 2006 15:24:56 -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, 27 Oct 2006 18:24:55 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 18:24:55 -0400 Message-ID: <45428736.8070105@cisco.com> Date: Fri, 27 Oct 2006 18:24:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 22:24:55.0319 (UTC) FILETIME=[BA950270:01C6FA16] DKIM-Signature: a=rsa-sha1; q=dns; l=3278; t=1161987896; x=1162851896; c=relaxed/simple; s=sjdkim5002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D8T2qLW38YZ2FX38zFN0RkJYv1P0=3D; b=Xiay+IdFuOjymi+A3cm3f8ewEQhs0yaIGH4ubmokQQnXpF+Aid55ANKDhriCG6oazURFvO+n bn4TlPu9iyDixkChQPHagwtGVrqvyLmLyGyInKkXusw7mjX8y7AGaaSZ; Authentication-Results: sj-dkim-5.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "Joel M. Halpern" , 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 Francois Audet wrote: > The practical use is to be able to deploy hop-by-hop TLS-based SIP > signalling (using transitive trust), with the current RFC 3261 > complemented with the explanation of my draft, in the SHORT TERM. The problem I have with this is that it takes us from "the emperor is naked" to "the emperor is in his underwear". If you take a system built using SIP over UDP, and upgrade it to SIPS, what can you now put in your sales brochure that you couldn't put before? Apparently you can't now advertise "secure calling" or put a little lock icon on the display. All you can say is "we don't suck as bad as we used to". and you probably can't even realize this level of improvement on all calls. You still must be prepared for cases where you can't get SIPS. So I guess the claim must be "we don't suck as bad as we used to, on some calls". Maybe we could put a little "half ass" icon up when the call is via SIPS. How much extra investment does that justify? It seems like the best we could do is start deploying SIPS as a hidden cost of doing business, to try to get closer to what most customers no doubt assume is already there. But unless it is done quite ubiquitously it won't even help reduce the possibility of some really bad exploit happening. Paul > I.e., without waiting for SIP to develop the next protocol that > allows for other alternative security mechanisms. > > You have to understand that people ARE implementing sips today because > of market demand. They won't stop doing this because we promise them > that a few years from now, we'll have something better. > > I'd much rather have implementations that follow our recommendations > on that front, rather than have vastly different intrepretation of > RFC 3261's SIPS. If we don't have practical guidelines for the current > state of the art, that's exactly what will happen. > > I don't believe any of us is arguing that sips is the greatest thing > since slice bread. I don't think any of us is arguing that it is > unreasonable to use other protocols for securing SIP either (although > there is a split of opinions on if that should be called sips or not). > We are just saying that sips can relatively easily be made to work for > hop-by-hop TLS, in the short term. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 27, 2006 1:34 PM >> To: Audet, Francois (SC100:3055) >> Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List >> Subject: Re: [Sip] RE: TLS meaning >> >> Note that my comment and Brian's initial one on the same >> subject were independently and simultaneously created. As >> soon as I saw Brian's comment I knew he would be replying back to me. >> >> I don't dispute that making the necessary specifications will >> be hard. I don't know if it would be useful to attach the >> SIPS name to this new thing or not. It may be that some other >> way (e.g. Proxy-Require) would be better. Or maybe a scheme >> name, SIPS or something else, would really be good for it. >> >> But I'm so far not convinced that an all-TLS-based SIPS >> actually delivers anything that has a practical use. >> >> 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 Oct 27 18:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaJk-0000SS-Cs; Fri, 27 Oct 2006 18:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaJi-0000SN-TD for sip@ietf.org; Fri, 27 Oct 2006 18:36:46 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdaJO-0006cJ-1B for sip@ietf.org; Fri, 27 Oct 2006 18:36:46 -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 k9RMTUw04132; Fri, 27 Oct 2006 18:29: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] RE: TLS meaning Date: Fri, 27 Oct 2006 17:36:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> In-Reply-To: <45428736.8070105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6FsAokahIvVOtQn6fAu9nmqGOHgAAL2NQ From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: "Joel M. Halpern" , 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 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, October 27, 2006 3:25 PM > To: Audet, Francois (SC100:3055) > Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 >=20 >=20 > Francois Audet wrote: > > The practical use is to be able to deploy hop-by-hop TLS-based SIP=20 > > signalling (using transitive trust), with the current RFC 3261=20 > > complemented with the explanation of my draft, in the SHORT TERM. >=20 > The problem I have with this is that it takes us from "the=20 > emperor is naked" to "the emperor is in his underwear". >=20 > If you take a system built using SIP over UDP, and upgrade it=20 > to SIPS, what can you now put in your sales brochure that you=20 > couldn't put before? You can can deploy a network that allows sessions to be established end-to-end security using TLS. Provided of course that all the proxies are compliant (transitive trust). You can NOT do that today without SIPS because there is no way with SIP only to request that all hops be over TLS. It's as simple as that. It's not just a "sales brochure" thing. It's real funtionality. > Apparently you can't now advertise "secure calling" or put a=20 > little lock icon on the display. All you can say is "we don't=20 > suck as bad as we used to". and you probably can't even=20 > realize this level of improvement on all calls. You still=20 > must be prepared for cases where you can't get SIPS. So I=20 > guess the claim must be "we don't suck as bad as we used to,=20 > on some calls". Maybe we could put a little "half ass" icon=20 > up when the call is via SIPS. This has absolutely nothing to do with what SIPS is intended to do. The draft makes it clear sips !=3D padlock icon. Again, the whole idea is to allow for establishing a session to an address which implies that all hops will be over TLS. > How much extra investment does that justify? >=20 > It seems like the best we could do is start deploying SIPS as=20 > a hidden cost of doing business, to try to get closer to what=20 > most customers no doubt assume is already there. But unless=20 > it is done quite ubiquitously it won't even help reduce the=20 > possibility of some really bad exploit happening. I fail to see the relevance of this last paragraph to the discussion of sips. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 18:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaKv-00037h-Ey; Fri, 27 Oct 2006 18:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaKt-00037X-LI for sip@ietf.org; Fri, 27 Oct 2006 18:37:59 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdaKs-0006jU-6d for sip@ietf.org; Fri, 27 Oct 2006 18:37:59 -0400 Received: from [209.172.111.2] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GdaKr-0003Wu-1M; Fri, 27 Oct 2006 18:37:57 -0400 Message-Id: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 27 Oct 2006 18:37:47 -0400 To: EKR From: "Joel M. Halpern" Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120ac5bf900ac6cce4d38306af9ecab7261660b582bd1b8aac6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.172.111.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Part of what drove me to participate in this discussion is remembering a conversation with an operator who was deploying a SIP based service. They have (had?) IPSec tunnels between their proxies and other service provides' proxies. They know who is who. They don't need a TLS certificate from the other proxy. The security they are delivering is, as far as I can tell, as good as that delivered by any pure TLS mechanism. Possibly better than some. But, as written, what they have done is against the rules. And folks are complaining about it. (So, we have an operator actually delivering security, and we give him grief. This encourages security delivery?) Maybe there is some way in which their security was actually noticeably weaker. But it seems to me pretty strange for us to try to claim that such a deployment is insecure. And it seems to me that the user is getting what he wants when he uses it. Yours, Joel M. Halpern At 01:27 PM 10/27/2006, Dean Willis wrote: >On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > >>Dean Willis writes: >>>On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: >>>>Well, I do. The security (authentication) properties of IPsec are >>>>rather >>>>different then those of TLS. And why just say IPsec is OK. What >>>>about >>>>WEP? What Once you relax the meaning to "secure" then it's more or >>>>ess meaningless. >>> >>>Would you want it to fail if DTLS/DCCP were used instead of TLS/TCP? >> >>No, I don't see a problem with that. It seems to me that (D)TLS over >>any transport has basically the same security properties, which >>is the relevant issue here. > >That's useful to know. It might be possible to persuade the UDP fans >in mobile land to use DTLS. I'm hearing good things about DTLS from >other folks who have played with it on small systems. > >And I can clearly see that a blanket policy that would accept WEP as >"Secured" would be bad. > >But please help us understand what's different about IPSEC usage in >the IMS sense. > >IMS has a persistent IPSEC SA established between the edge proxy and >the UA. Authentication is accomplished using the SIM as a token >generator, and the crypto is one of the usual mechanisms (keep in >mind TLS still allows plain small-key DES, which isn't all that >strong). The applications are constructed so that the SIP function is >aware of the SA and that it is connected to an authenticated party. > >What is different about the security properties here from TLS in >outbound in such a way that it makes a difference to the SIP 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 Oct 27 18:43:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaO8-0006Pl-H6; Fri, 27 Oct 2006 18:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaO6-0006Hh-Hb for sip@ietf.org; Fri, 27 Oct 2006 18:41:18 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdaO5-0006zK-7A for sip@ietf.org; Fri, 27 Oct 2006 18:41:18 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id A88791E8C28; Fri, 27 Oct 2006 15:41:16 -0700 (PDT) To: "Joel M. Halpern" Subject: Re: [Sip] RE: TLS meaning References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 15:41:16 -0700 In-Reply-To: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> (Joel M. Halpern's message of "Fri, 27 Oct 2006 18:37:47 -0400") Message-ID: <86odrxjsab.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: 'IETF SIP List' 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 "Joel M. Halpern" writes: > Part of what drove me to participate in this discussion is remembering > a conversation with an operator who was deploying a SIP based service. > They have (had?) IPSec tunnels between their proxies and other service > provides' proxies. They know who is who. They don't need a TLS > certificate from the other proxy. The security they are delivering is, > as far as I can tell, as good as that delivered by any pure TLS > mechanism. Possibly better than some. > But, as written, what they have done is against the rules. > And folks are complaining about it. > (So, we have an operator actually delivering security, and we give him > grief. This encourages security delivery?) > > Maybe there is some way in which their security was actually > noticeably weaker. But it seems to me pretty strange for us to try > to claim that such a deployment is insecure. And it seems to me > that the user is getting what he wants when he uses it. Who's claiming that it's insecure? I said it was noncompliant, not insecure. Anyway, it's not at all clear that an IPsec tunnel is actually as good as TLS in this context. Is this a host-to-host tunnel or a VPN? What's in the certificate, a domain name or an IP address? There are lots of ways to bungle this with IPsec--and of course with TLS too, but the difference is that we've profiled tLS here. -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 Oct 27 19:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdafa-0001P0-Df; Fri, 27 Oct 2006 18:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdafZ-0001Ob-Iu for sip@ietf.org; Fri, 27 Oct 2006 18:59:21 -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 1GdafY-0008MO-7g for sip@ietf.org; Fri, 27 Oct 2006 18:59:21 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2006 15:59:19 -0700 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 k9RMxJmx001312; Fri, 27 Oct 2006 15:59:19 -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 k9RMxJW4005790; Fri, 27 Oct 2006 15:59:19 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-497.cisco.com [10.21.153.241]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RMkiCj024315; Fri, 27 Oct 2006 15:46:44 -0700 Message-ID: <45428F46.1070308@cisco.com> Date: Fri, 27 Oct 2006 15:59:18 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; 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=2586; t=1161989959; x=1162853959; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=xZ4IlzxZZqoWSLqpTp6529G8wgtSXukuOodzYQIkwdZQozQIrEBAp5TSSkC0DpYncHCWWIsE qbl0VZ/CNtWsSeCVwf/eTH9buVIiYXtK8q7435WGUmMnckqCJtNemGBR; X-Spam-Score: 1.8 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Joel M. Halpern" , 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 Francois Audet wrote: >>If you take a system built using SIP over UDP, and upgrade it >>to SIPS, what can you now put in your sales brochure that you >>couldn't put before? >> >> > >You can can deploy a network that allows sessions to be established >end-to-end security using TLS. Provided of course that all the proxies >are compliant (transitive trust). > > No, no, no, no, no, NO! This is *exactly* why this is such an absolute crock. That is *not* end-to-end security. This is exactly why sanctioning this half-baked scheme is so dangerous. Harmful, even. It's bad enough when sales droids embrace and extend the truth, but when you give them something that is so trivial to get completely wrong and not even requiring so much as a grin f*ck... that's a problem. Mike >You can NOT do that today without SIPS because there is no way >with SIP only to request that all hops be over TLS. > >It's as simple as that. > >It's not just a "sales brochure" thing. It's real funtionality. > > > >>Apparently you can't now advertise "secure calling" or put a >>little lock icon on the display. All you can say is "we don't >>suck as bad as we used to". and you probably can't even >>realize this level of improvement on all calls. You still >>must be prepared for cases where you can't get SIPS. So I >>guess the claim must be "we don't suck as bad as we used to, >>on some calls". Maybe we could put a little "half ass" icon >>up when the call is via SIPS. >> >> > >This has absolutely nothing to do with what SIPS is intended to >do. > >The draft makes it clear sips != padlock icon. > >Again, the whole idea is to allow for establishing a session to >an address which implies that all hops will be over TLS. > > > >>How much extra investment does that justify? >> >>It seems like the best we could do is start deploying SIPS as >>a hidden cost of doing business, to try to get closer to what >>most customers no doubt assume is already there. But unless >>it is done quite ubiquitously it won't even help reduce the >>possibility of some really bad exploit happening. >> >> > >I fail to see the relevance of this last paragraph to the discussion >of sips. > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP 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 Oct 27 19:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxL-0007hV-BI; Fri, 27 Oct 2006 19:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxJ-0007gA-HF for sip@ietf.org; Fri, 27 Oct 2006 19:17:41 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdalX-0000PZ-Jm for sip@ietf.org; Fri, 27 Oct 2006 19:05:32 -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 k9RN5RP01526; Fri, 27 Oct 2006 19:05: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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:05:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2961D@zrc2hxm0.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6GKd+nmMqQj+XRUC2psW45byWKQAA5kMA From: "Francois Audet" To: "Joel M. Halpern" , "EKR" X-Spam-Score: 0.0 (/) 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 Joel, there is nothing wrong with this. Nobody said it was insecure. It just is not sips.=20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, October 27, 2006 3:38 PM > To: EKR > Cc: 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning >=20 > Part of what drove me to participate in this discussion is=20 > remembering a conversation with an operator who was deploying=20 > a SIP based service. They have (had?) IPSec tunnels between=20 > their proxies and other service provides' proxies. They know=20 > who is who. They don't need a TLS certificate from the other=20 > proxy. The security they are delivering is, as far as I can=20 > tell, as good as that delivered by any pure TLS mechanism. =20 > Possibly better than some. > But, as written, what they have done is against the rules. > And folks are complaining about it. > (So, we have an operator actually delivering security, and we=20 > give him grief. This encourages security delivery?) >=20 > Maybe there is some way in which their security was actually=20 > noticeably weaker. > But it seems to me pretty strange for us to try to claim that=20 > such a deployment is insecure. > And it seems to me that the user is getting what he wants=20 > when he uses it. >=20 > Yours, > Joel M. Halpern >=20 > At 01:27 PM 10/27/2006, Dean Willis wrote: >=20 > >On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > > > >>Dean Willis writes: > >>>On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >>>>Well, I do. The security (authentication) properties of IPsec are=20 > >>>>rather different then those of TLS. And why just say IPsec is OK.=20 > >>>>What about WEP? What Once you relax the meaning to "secure" then=20 > >>>>it's more or ess meaningless. > >>> > >>>Would you want it to fail if DTLS/DCCP were used instead=20 > of TLS/TCP? > >> > >>No, I don't see a problem with that. It seems to me that=20 > (D)TLS over=20 > >>any transport has basically the same security properties,=20 > which is the=20 > >>relevant issue here. > > > >That's useful to know. It might be possible to persuade the=20 > UDP fans in=20 > >mobile land to use DTLS. I'm hearing good things about DTLS=20 > from other=20 > >folks who have played with it on small systems. > > > >And I can clearly see that a blanket policy that would accept WEP as=20 > >"Secured" would be bad. > > > >But please help us understand what's different about IPSEC=20 > usage in the=20 > >IMS sense. > > > >IMS has a persistent IPSEC SA established between the edge proxy and=20 > >the UA. Authentication is accomplished using the SIM as a token=20 > >generator, and the crypto is one of the usual mechanisms=20 > (keep in mind=20 > >TLS still allows plain small-key DES, which isn't all that=20 > strong). The=20 > >applications are constructed so that the SIP function is=20 > aware of the=20 > >SA and that it is connected to an authenticated party. > > > >What is different about the security properties here from TLS in=20 > >outbound in such a way that it makes a difference to the SIP user? > > > >-- > >Dean > > >=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 Oct 27 19:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxG-0007gk-Ho; Fri, 27 Oct 2006 19:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxF-0007gA-8q for sip@ietf.org; Fri, 27 Oct 2006 19:17:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdamc-0000TT-JZ for sip@ietf.org; Fri, 27 Oct 2006 19:06:39 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 16:06:38 -0700 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 k9RN6cCu009830; Fri, 27 Oct 2006 16:06:38 -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 k9RN6ROV026195; Fri, 27 Oct 2006 16:06:31 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-497.cisco.com [10.21.153.241]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RMrqDC024477; Fri, 27 Oct 2006 15:53:52 -0700 Message-ID: <454290F2.2010501@cisco.com> Date: Fri, 27 Oct 2006 16:06:26 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> <86iri5n3cz.fsf@raman.networkresonance.com> <45426305.6060904@cisco.com> <86u01pldjx.fsf@raman.networkresonance.com> In-Reply-To: <86u01pldjx.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-6.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1045; t=1161990398; x=1162854398; c=relaxed/simple; s=sjdkim6002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=is8Ev9oPW4rfhfm5LoptfUy4qyVGL1Gt/rx3Hw+YDrItoUCRlcaZ5rGJ8eHdBkBWEGmApcKR p2Jf9jkdbR8aCzIB88o2u0uj8WeyfOTZMQSlVek0E9WRlRYwuOm+8BnT; X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Eric Rescorla wrote: >Michael Thomas writes: > > > >Funny, what I remember about five years ago was that you were >mostly doing the same kind of complaining you're doing now, >so pardon me if I don't consider the fact that you're unhappy >with SIPS to be a total showstopper. > > Funny, your memory is wrong. I was there for the first real SIP security get together in, what, Adalaide? You weren't. I wrote a problems/framework draft, and was active in the Packetcable voice security specification which predates any of this including SRTP. As I recall, your first introduction was on the complaining side, not the specifying side right before 3261 was about to go to last call. So here we are, 5 years later. Boy oh boy, that big dollop of "security" that got thrown in at the last minute sure was a godsend. Heavens, what would we have done without S/MIME and SIPS? Silly me to think that separating out the problems so they actually fit the requirements was a better plan. 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 Oct 27 19:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxL-0007hV-BI; Fri, 27 Oct 2006 19:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxJ-0007gA-HF for sip@ietf.org; Fri, 27 Oct 2006 19:17:41 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdalX-0000PZ-Jm for sip@ietf.org; Fri, 27 Oct 2006 19:05:32 -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 k9RN5RP01526; Fri, 27 Oct 2006 19:05: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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:05:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2961D@zrc2hxm0.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6GKd+nmMqQj+XRUC2psW45byWKQAA5kMA From: "Francois Audet" To: "Joel M. Halpern" , "EKR" X-Spam-Score: 0.0 (/) 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 Joel, there is nothing wrong with this. Nobody said it was insecure. It just is not sips.=20 > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 > Sent: Friday, October 27, 2006 3:38 PM > To: EKR > Cc: 'IETF SIP List' > Subject: Re: [Sip] RE: TLS meaning >=20 > Part of what drove me to participate in this discussion is=20 > remembering a conversation with an operator who was deploying=20 > a SIP based service. They have (had?) IPSec tunnels between=20 > their proxies and other service provides' proxies. They know=20 > who is who. They don't need a TLS certificate from the other=20 > proxy. The security they are delivering is, as far as I can=20 > tell, as good as that delivered by any pure TLS mechanism. =20 > Possibly better than some. > But, as written, what they have done is against the rules. > And folks are complaining about it. > (So, we have an operator actually delivering security, and we=20 > give him grief. This encourages security delivery?) >=20 > Maybe there is some way in which their security was actually=20 > noticeably weaker. > But it seems to me pretty strange for us to try to claim that=20 > such a deployment is insecure. > And it seems to me that the user is getting what he wants=20 > when he uses it. >=20 > Yours, > Joel M. Halpern >=20 > At 01:27 PM 10/27/2006, Dean Willis wrote: >=20 > >On Oct 27, 2006, at 11:44 AM, Eric Rescorla wrote: > > > >>Dean Willis writes: > >>>On Oct 27, 2006, at 10:47 AM, Eric Rescorla wrote: > >>>>Well, I do. The security (authentication) properties of IPsec are=20 > >>>>rather different then those of TLS. And why just say IPsec is OK.=20 > >>>>What about WEP? What Once you relax the meaning to "secure" then=20 > >>>>it's more or ess meaningless. > >>> > >>>Would you want it to fail if DTLS/DCCP were used instead=20 > of TLS/TCP? > >> > >>No, I don't see a problem with that. It seems to me that=20 > (D)TLS over=20 > >>any transport has basically the same security properties,=20 > which is the=20 > >>relevant issue here. > > > >That's useful to know. It might be possible to persuade the=20 > UDP fans in=20 > >mobile land to use DTLS. I'm hearing good things about DTLS=20 > from other=20 > >folks who have played with it on small systems. > > > >And I can clearly see that a blanket policy that would accept WEP as=20 > >"Secured" would be bad. > > > >But please help us understand what's different about IPSEC=20 > usage in the=20 > >IMS sense. > > > >IMS has a persistent IPSEC SA established between the edge proxy and=20 > >the UA. Authentication is accomplished using the SIM as a token=20 > >generator, and the crypto is one of the usual mechanisms=20 > (keep in mind=20 > >TLS still allows plain small-key DES, which isn't all that=20 > strong). The=20 > >applications are constructed so that the SIP function is=20 > aware of the=20 > >SA and that it is connected to an authenticated party. > > > >What is different about the security properties here from TLS in=20 > >outbound in such a way that it makes a difference to the SIP user? > > > >-- > >Dean > > >=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 Oct 27 19:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxG-0007gk-Ho; Fri, 27 Oct 2006 19:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxF-0007gA-8q for sip@ietf.org; Fri, 27 Oct 2006 19:17:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdamc-0000TT-JZ for sip@ietf.org; Fri, 27 Oct 2006 19:06:39 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2006 16:06:38 -0700 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 k9RN6cCu009830; Fri, 27 Oct 2006 16:06:38 -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 k9RN6ROV026195; Fri, 27 Oct 2006 16:06:31 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-497.cisco.com [10.21.153.241]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RMrqDC024477; Fri, 27 Oct 2006 15:53:52 -0700 Message-ID: <454290F2.2010501@cisco.com> Date: Fri, 27 Oct 2006 16:06:26 -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: EKR Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> <86iri5n3cz.fsf@raman.networkresonance.com> <45426305.6060904@cisco.com> <86u01pldjx.fsf@raman.networkresonance.com> In-Reply-To: <86u01pldjx.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-6.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1045; t=1161990398; x=1162854398; c=relaxed/simple; s=sjdkim6002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=is8Ev9oPW4rfhfm5LoptfUy4qyVGL1Gt/rx3Hw+YDrItoUCRlcaZ5rGJ8eHdBkBWEGmApcKR p2Jf9jkdbR8aCzIB88o2u0uj8WeyfOTZMQSlVek0E9WRlRYwuOm+8BnT; X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Eric Rescorla wrote: >Michael Thomas writes: > > > >Funny, what I remember about five years ago was that you were >mostly doing the same kind of complaining you're doing now, >so pardon me if I don't consider the fact that you're unhappy >with SIPS to be a total showstopper. > > Funny, your memory is wrong. I was there for the first real SIP security get together in, what, Adalaide? You weren't. I wrote a problems/framework draft, and was active in the Packetcable voice security specification which predates any of this including SRTP. As I recall, your first introduction was on the complaining side, not the specifying side right before 3261 was about to go to last call. So here we are, 5 years later. Boy oh boy, that big dollop of "security" that got thrown in at the last minute sure was a godsend. Heavens, what would we have done without S/MIME and SIPS? Silly me to think that separating out the problems so they actually fit the requirements was a better plan. 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 Oct 27 19:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdazm-0000Fm-TK; Fri, 27 Oct 2006 19:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdazm-0000FP-7I for sip@ietf.org; Fri, 27 Oct 2006 19:20:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdazk-0001Qa-VA for sip@ietf.org; Fri, 27 Oct 2006 19:20:14 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 16:20: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 k9RNKCQo017055; Fri, 27 Oct 2006 16:20: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 k9RNKCAo011430; Fri, 27 Oct 2006 16:20:12 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-497.cisco.com [10.21.153.241]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RN7WDP024767; Fri, 27 Oct 2006 16:07:35 -0700 Message-ID: <45429425.1020602@cisco.com> Date: Fri, 27 Oct 2006 16:20:05 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC29624@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC29624@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; 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=781; t=1161991212; x=1162855212; 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:Re=3A=20[Sip]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=PQF5//Sg82Lp3UbYzScGpPrQS/f8Lbdx0ZYLcNeIN0hWowcMT/fI56iBbPV/DhPl6VfCHQvV nc/HCvq6k97C8rbpNEaAUisEQ1hOlqYmYXUpo01hd6/xRS2q8D+9PdH9; X-Spam-Score: 1.8 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Francois Audet wrote: >Please calm down. > >Here is one simple scenario. > >I deploy an Enteprise SIP network. I install 10 SIP proxies >accross the Corporate Network. All the proxies are certified to >properly implement SIPS. All the phones are also certified to >implement SIPS properly. I know, because I am responsible for the >network. > >An end user can call another end-user within that network >with the certitude that if sips is used, it will be secured >end-to-end. > How about an example when it's not all within the same administrative entity. How abouts some examples that resemble, oh say, the mail system. These have always been where my concerns are. Within my own domain, I don't need SIPS; I can do that by executive fiat. 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 Oct 27 19:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb1P-0001e5-FV; Fri, 27 Oct 2006 19:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb1O-0001dJ-5x for sip@ietf.org; Fri, 27 Oct 2006 19:21:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdb1M-0001Z3-Re for sip@ietf.org; Fri, 27 Oct 2006 19:21:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2006 19:21:53 -0400 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 k9RNLqJ8015669; Fri, 27 Oct 2006 19:21:52 -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 k9RNLqYJ009657; Fri, 27 Oct 2006 19:21: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); Fri, 27 Oct 2006 19:21:52 -0400 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 19:21:51 -0400 Message-ID: <4542948F.8060004@cisco.com> Date: Fri, 27 Oct 2006 19:21:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2006 23:21:51.0681 (UTC) FILETIME=[AEE47B10:01C6FA1E] DKIM-Signature: a=rsa-sha1; q=dns; l=3863; t=1161991312; x=1162855312; 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]=20RE=3A=20TLS=20meaning |To:Francois=20Audet=20; X=v=3Dcisco.com=3B=20h=3D8T2qLW38YZ2FX38zFN0RkJYv1P0=3D; b=lZv57QA20lU9z/Yl0V1tCl/ZoLbujHPg8e+naI0m4rachEYkIW7UJXOt0u5+ux3ugz/fSeoV 8lulYCz+7p154fxifYHtwLbbWw4Kq5pJgKhrlHR9kwuBASAzXP/Z9dxp; 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: a2c12dacc0736f14d6b540e805505a86 Cc: "Joel M. Halpern" , 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 Francois Audet wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, October 27, 2006 3:25 PM >> To: Audet, Francois (SC100:3055) >> Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List >> Subject: Re: [Sip] RE: TLS meaning >> >> >> >> Francois Audet wrote: >>> The practical use is to be able to deploy hop-by-hop TLS-based SIP >>> signalling (using transitive trust), with the current RFC 3261 >>> complemented with the explanation of my draft, in the SHORT TERM. >> The problem I have with this is that it takes us from "the >> emperor is naked" to "the emperor is in his underwear". >> >> If you take a system built using SIP over UDP, and upgrade it >> to SIPS, what can you now put in your sales brochure that you >> couldn't put before? > > You can can deploy a network that allows sessions to be established > end-to-end security using TLS. Provided of course that all the proxies > are compliant (transitive trust). > > You can NOT do that today without SIPS because there is no way > with SIP only to request that all hops be over TLS. > > It's as simple as that. WHY would you do that, rather than just use SIP over UDP or TCP? Presumably because you think it makes something better that somebody cares about. What is that? > It's not just a "sales brochure" thing. It's real funtionality. What functionality is it? Do people pay extra to get it? What is it you tell them to get them to pay extra? >> Apparently you can't now advertise "secure calling" or put a >> little lock icon on the display. All you can say is "we don't >> suck as bad as we used to". and you probably can't even >> realize this level of improvement on all calls. You still >> must be prepared for cases where you can't get SIPS. So I >> guess the claim must be "we don't suck as bad as we used to, >> on some calls". Maybe we could put a little "half ass" icon >> up when the call is via SIPS. > > This has absolutely nothing to do with what SIPS is intended to > do. > > The draft makes it clear sips != padlock icon. > > Again, the whole idea is to allow for establishing a session to > an address which implies that all hops will be over TLS. > >> How much extra investment does that justify? >> >> It seems like the best we could do is start deploying SIPS as >> a hidden cost of doing business, to try to get closer to what >> most customers no doubt assume is already there. But unless >> it is done quite ubiquitously it won't even help reduce the >> possibility of some really bad exploit happening. > > I fail to see the relevance of this last paragraph to the discussion > of sips. When you put in SIPS, do you make *all* calls be SIPS? If not, how do you deal with the ones that are vs those that aren't? For example: maybe you build a "SIPS PBX" that uses SIPS throughout the enterprise where it is deployed. The next wanted is SIP-based trunking to a service provider. Hopefully the SP is interested in supporting SIPS. But do you insist the SP use TLS throughout? Or maybe just to an SBC. (After all, an SBC is a UA, so it terminates the call.) Maybe it does SIP over IPsec on the other side. Is that ok? What if that SP also terminates other enterprises that you sometimes call. And not all of them support SIPS. What happens when you call them? Do your calls have to hairpin through the PSTN because that is the only legal way to get from SIPS to SIP? Or do you somehow discover they only do SIP, so you use SIP when calling them? Let me restate one question above because I think it might be a big deal: How does SIPS work with B2BUAs/SBCs? Is it ok for an SBC to splice together a SIPS call and a SIP call? Do anybody believe this won't happen? 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 Oct 27 19:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb1s-0002mV-TL; Fri, 27 Oct 2006 19:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxA-0007dV-LT for sip@ietf.org; Fri, 27 Oct 2006 19:17:32 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdasF-0000jG-MZ for sip@ietf.org; Fri, 27 Oct 2006 19:12:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D2D861E8C28; Fri, 27 Oct 2006 16:12:24 -0700 (PDT) To: Michael Thomas Subject: Re: [Sip] RE: TLS meaning References: <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <45422830.4040700@cisco.com> <86u01pn3u3.fsf@raman.networkresonance.com> <45422F2C.2080300@cisco.com> <86iri5n3cz.fsf@raman.networkresonance.com> <45426305.6060904@cisco.com> <86u01pldjx.fsf@raman.networkresonance.com> <454290F2.2010501@cisco.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 16:12:24 -0700 In-Reply-To: <454290F2.2010501@cisco.com> (Michael Thomas's message of "Fri, 27 Oct 2006 16:06:26 -0700") Message-ID: <86ejstjquf.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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ext Cullen Jennings' , "Peterson, Jon" , 'IETF SIP List' , 'Francois Audet' , '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 Michael Thomas writes: > Eric Rescorla wrote: > >>Michael Thomas writes: >> >> >> >>Funny, what I remember about five years ago was that you were >>mostly doing the same kind of complaining you're doing now, >>so pardon me if I don't consider the fact that you're unhappy >>with SIPS to be a total showstopper. >> >> > Funny, your memory is wrong. I was there for the first real SIP > security get together > in, what, Adalaide? You weren't. I wrote a problems/framework draft, > and was > active in the Packetcable voice security specification which predates > any of this > including SRTP. As I recall, your first introduction was on the > complaining side, > not the specifying side right before 3261 was about to go to last call. > So here we are, 5 years later. Boy oh boy, that big dollop of > "security" that got > thrown in at the last minute sure was a godsend. Heavens, what would we have > done without S/MIME and SIPS? Silly me to think that separating out > the problems > so they actually fit the requirements was a better plan. You know, I considered responding to this, but honestly, it's just not worth my time. Wake me up when you're prepared to have a technical discussion without the invective. -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 Oct 27 19:24:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb1u-0002of-36; Fri, 27 Oct 2006 19:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxA-0007dV-PC for sip@ietf.org; Fri, 27 Oct 2006 19:17:32 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdarp-0000gQ-RQ for sip@ietf.org; Fri, 27 Oct 2006 19:12:03 -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 k9RNBnM18302; Fri, 27 Oct 2006 19:11: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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:11:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC29624@zrc2hxm0.corp.nortel.com> In-Reply-To: <45428F46.1070308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6G4ttxMuktiQCSs+olxufjVmglAAADFdw From: "Francois Audet" To: "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Please calm down. Here is one simple scenario. I deploy an Enteprise SIP network. I install 10 SIP proxies=20 accross the Corporate Network. All the proxies are certified to=20 properly implement SIPS. All the phones are also certified to implement SIPS properly. I know, because I am responsible for the network. An end user can call another end-user within that network with the certitude that if sips is used, it will be secured end-to-end. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Friday, October 27, 2006 3:59 PM > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; Joel M. Halpern; IETF SIP List; Dean Willis > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >>If you take a system built using SIP over UDP, and upgrade=20 > it to SIPS,=20 > >>what can you now put in your sales brochure that you couldn't put=20 > >>before? > >> =20 > >> > > > >You can can deploy a network that allows sessions to be established=20 > >end-to-end security using TLS. Provided of course that all=20 > the proxies=20 > >are compliant (transitive trust). > > =20 > > > No, no, no, no, no, NO! This is *exactly* why this is such an=20 > absolute crock. > That is *not* end-to-end security. This is exactly why=20 > sanctioning this half-baked scheme is so dangerous. Harmful,=20 > even. It's bad enough when sales droids embrace and extend=20 > the truth, but when you give them something that is so=20 > trivial to get completely wrong and not even requiring so=20 > much as a grin f*ck... > that's a problem. >=20 > Mike >=20 > >You can NOT do that today without SIPS because there is no=20 > way with SIP=20 > >only to request that all hops be over TLS. > > > >It's as simple as that. > > > >It's not just a "sales brochure" thing. It's real funtionality. > > > > =20 > > > >>Apparently you can't now advertise "secure calling" or put a little=20 > >>lock icon on the display. All you can say is "we don't suck=20 > as bad as=20 > >>we used to". and you probably can't even realize this level of=20 > >>improvement on all calls. You still must be prepared for=20 > cases where=20 > >>you can't get SIPS. So I guess the claim must be "we don't=20 > suck as bad=20 > >>as we used to, on some calls". Maybe we could put a little=20 > "half ass"=20 > >>icon up when the call is via SIPS. > >> =20 > >> > > > >This has absolutely nothing to do with what SIPS is intended to > >do. > > > >The draft makes it clear sips !=3D padlock icon. > > > >Again, the whole idea is to allow for establishing a session to > >an address which implies that all hops will be over TLS. > > > > =20 > > > >>How much extra investment does that justify? > >> > >>It seems like the best we could do is start deploying SIPS as=20 > >>a hidden cost of doing business, to try to get closer to what=20 > >>most customers no doubt assume is already there. But unless=20 > >>it is done quite ubiquitously it won't even help reduce the=20 > >>possibility of some really bad exploit happening. > >> =20 > >> > > > >I fail to see the relevance of this last paragraph to the discussion > >of sips. > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP 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 From sip-bounces@ietf.org Fri Oct 27 19:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb63-000418-7C; Fri, 27 Oct 2006 19:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb61-0003wI-Kg for sip@ietf.org; Fri, 27 Oct 2006 19:26:41 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdb60-0001zg-73 for sip@ietf.org; Fri, 27 Oct 2006 19:26:41 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9RNQdnh004955 for ; Fri, 27 Oct 2006 17:26:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 17:26:38 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback Requested: draft-johns-sip-outbound-middialog Thread-Index: Acb6H1j9RfrmSIr7QV6kwMD2hyiNtw== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Sip] Feedback Requested: draft-johns-sip-outbound-middialog X-BeenThere: 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="===============1210970716==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1210970716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FA1F.59BA7A62" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FA1F.59BA7A62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 The topic of routing mid-dialog requests when using outbound procedures was documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-00 and subsequently presented at IETF#65 (see http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the meeting and other offline discussions, an updated Internet Draft was submitted and is now available at: =20 http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-01 =20 The updates are primarily around clarifying the use case and illustrative call flow, the proposed solution has not changed. =20 The Abstract is reproduced for the benefit of folks not involved in earlier discussions: =20 " This document describes modifications to the procedures for the generation of a flow token as described in the Internet Draft titled Managing Client Initiated Connections in the Session Initiation Protocol. This modification is necessary to support routing of mid- dialog requests while preserving Edge Proxy failover within an outbound-proxy-set." =20 Would appreciate comments and interest. =20 Thanks Kevin =20 =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C6FA1F.59BA7A62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ; Fri, 27 Oct 2006 17:26:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Oct 2006 17:26:38 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback Requested: draft-johns-sip-outbound-middialog Thread-Index: Acb6H1j9RfrmSIr7QV6kwMD2hyiNtw== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Sip] Feedback Requested: draft-johns-sip-outbound-middialog X-BeenThere: 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="===============1210970716==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1210970716== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FA1F.59BA7A62" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FA1F.59BA7A62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 The topic of routing mid-dialog requests when using outbound procedures was documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-00 and subsequently presented at IETF#65 (see http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the meeting and other offline discussions, an updated Internet Draft was submitted and is now available at: =20 http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-01 =20 The updates are primarily around clarifying the use case and illustrative call flow, the proposed solution has not changed. =20 The Abstract is reproduced for the benefit of folks not involved in earlier discussions: =20 " This document describes modifications to the procedures for the generation of a flow token as described in the Internet Draft titled Managing Client Initiated Connections in the Session Initiation Protocol. This modification is necessary to support routing of mid- dialog requests while preserving Edge Proxy failover within an outbound-proxy-set." =20 Would appreciate comments and interest. =20 Thanks Kevin =20 =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C6FA1F.59BA7A62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
The topic of routing mid-dialog requests when = using=20 outbound procedures was documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialo= g-draft-00 and subsequently presented at IETF#65 (see = http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the = meeting and=20 other offline discussions, an updated Internet Draft was submitted and = is now=20 available at:
 
http://tools.ietf.org/html/draft-johns-sip-outbound-middialo= g-draft-01
 
The updates are primarily around clarifying the = use case=20 and illustrative call flow, the proposed solution has not = changed.
 
The Abstract is reproduced for the benefit of = folks not=20 involved in earlier discussions:
 
" This document describes modifications to the = procedures=20 for the
generation of a flow token as described in the = Internet=20 Draft titled
Managing Client Initiated Connections in the = Session=20 Initiation
Protocol. This modification is necessary to = support=20 routing of mid-
dialog requests while preserving Edge Proxy = failover=20 within an
outbound-proxy-set."
 
Would appreciate comments and = interest.
 
Thanks
Kevin
 
 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C6FA1F.59BA7A62-- --===============1210970716== 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 --===============1210970716==-- From sip-bounces@ietf.org Fri Oct 27 19:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb5Y-0003TA-8A; Fri, 27 Oct 2006 19:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb5W-0003Thttp-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii">
Folks,
 
The topic of routing mid-dialog requests when = using=20 outbound procedures was documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialo= g-draft-00 and subsequently presented at IETF#65 (see = http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the = meeting and=20 other offline discussions, an updated Internet Draft was submitted and = is now=20 available at:
 
http://tools.ietf.org/html/draft-johns-sip-outbound-middialo= g-draft-01
 
The updates are primarily around clarifying the = use case=20 and illustrative call flow, the proposed solution has not = changed.
 
The Abstract is reproduced for the benefit of = folks not=20 involved in earlier discussions:
 
" This document describes modifications to the = procedures=20 for the
generation of a flow token as described in the = Internet=20 Draft titled
Managing Client Initiated Connections in the = Session=20 Initiation
Protocol. This modification is necessary to = support=20 routing of mid-
dialog requests while preserving Edge Proxy = failover=20 within an
outbound-proxy-set."
 
Would appreciate comments and = interest.
 
Thanks
Kevin
 
 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C6FA1F.59BA7A62-- --===============1210970716== 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 --===============1210970716==-- From sip-bounces@ietf.org Fri Oct 27 19:28:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb5Y-0003TA-8A; Fri, 27 Oct 2006 19:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb5W-0003T5-Ny for sip@ietf.org; Fri, 27 Oct 2006 19:26:10 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdb5V-0001wM-FN for sip@ietf.org; Fri, 27 Oct 2006 19:26:10 -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 k9RNQ5P04415; Fri, 27 Oct 2006 19:26:06 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:26:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> In-Reply-To: <45429425.1020602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6HnaoraB5KHLIS0ikZAADrG7rQQAAIYUA From: "Francois Audet" To: "Michael Thomas" 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 =20 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Friday, October 27, 2006 4:20 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >Please calm down. > > > >Here is one simple scenario. > > > >I deploy an Enteprise SIP network. I install 10 SIP proxies=20 > accross the=20 > >Corporate Network. All the proxies are certified to properly=20 > implement=20 > >SIPS. All the phones are also certified to implement SIPS=20 > properly. I=20 > >know, because I am responsible for the network. > > > >An end user can call another end-user within that network with the=20 > >certitude that if sips is used, it will be secured end-to-end. > > >=20 > How about an example when it's not all within the same=20 > administrative entity. How abouts some examples that=20 > resemble, oh say, the mail system. > These have always been where my concerns are. Within my own=20 > domain, I don't need SIPS; I can do that by executive fiat. In that case, if you don't have trust with them, then don't use sips. As simple as that. Yes you need sips in your own domain, because some devices support TLS,=20 others don't. Some users want to be addressed securily, others don't. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip 5-Ny for sip@ietf.org; Fri, 27 Oct 2006 19:26:10 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdb5V-0001wM-FN for sip@ietf.org; Fri, 27 Oct 2006 19:26:10 -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 k9RNQ5P04415; Fri, 27 Oct 2006 19:26:06 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:26:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> In-Reply-To: <45429425.1020602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6HnaoraB5KHLIS0ikZAADrG7rQQAAIYUA From: "Francois Audet" To: "Michael Thomas" 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 =20 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com]=20 > Sent: Friday, October 27, 2006 4:20 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: [Sip] RE: TLS meaning >=20 > Francois Audet wrote: >=20 > >Please calm down. > > > >Here is one simple scenario. > > > >I deploy an Enteprise SIP network. I install 10 SIP proxies=20 > accross the=20 > >Corporate Network. All the proxies are certified to properly=20 > implement=20 > >SIPS. All the phones are also certified to implement SIPS=20 > properly. I=20 > >know, because I am responsible for the network. > > > >An end user can call another end-user within that network with the=20 > >certitude that if sips is used, it will be secured end-to-end. > > >=20 > How about an example when it's not all within the same=20 > administrative entity. How abouts some examples that=20 > resemble, oh say, the mail system. > These have always been where my concerns are. Within my own=20 > domain, I don't need SIPS; I can do that by executive fiat. In that case, if you don't have trust with them, then don't use sips. As simple as that. Yes you need sips in your own domain, because some devices support TLS,=20 others don't. Some users want to be addressed securily, others don't. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 19:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb9k-0001BC-Ok; Fri, 27 Oct 2006 19:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdb9j-0001B6-CB for sip@ietf.org; Fri, 27 Oct 2006 19:30:31 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdb9i-0002PO-45 for sip@ietf.org; Fri, 27 Oct 2006 19:30:31 -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 k9RNUQq24531; Fri, 27 Oct 2006 19:30:26 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:30:25 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F4B25F4@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC29624@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6G4ttxMuktiQCSs+olxufjVmglAAADFdwAAD6b5A= From: "Samir Srivastava" To: "Francois Audet" , "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 am just catching up in the reverse order of mails.=20 Typical NAT mentality... Polluting the protocol. My VISION is of SIPNET ... Thx Samir >=20 > Please calm down. >=20 > Here is one simple scenario. >=20 > I deploy an Enteprise SIP network. I install 10 SIP proxies > accross the Corporate Network. All the proxies are certified to > properly implement SIPS. All the phones are also certified to > implement SIPS properly. I know, because I am responsible for the > network. >=20 > An end user can call another end-user within that network > with the certitude that if sips is used, it will be secured > end-to-end. >=20 >=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 Fri Oct 27 19:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbBw-0005PI-QW; Fri, 27 Oct 2006 19:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbBv-0005O1-23 for sip@ietf.org; Fri, 27 Oct 2006 19:32:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdbBt-0002cV-Oi for sip@ietf.org; Fri, 27 Oct 2006 19:32:47 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2006 16:32:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9RNWj02032513; Fri, 27 Oct 2006 16:32:45 -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 k9RNWjin006605; Fri, 27 Oct 2006 16:32:45 -0700 (PDT) Received: from [216.102.208.13] (sjc-vpn-hwcore-497.cisco.com [10.21.153.241]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9RNKAsb025039; Fri, 27 Oct 2006 16:20:10 -0700 Message-ID: <4542971C.3080706@cisco.com> Date: Fri, 27 Oct 2006 16:32:44 -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: Francois Audet Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1916; t=1161991965; x=1162855965; c=relaxed/simple; s=sjdkim1002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3D1GsuDSiA2v9kYoGCLcomcEiV93I=3D; b=DT7YBEPT9Dx+WV3CegCMAIWW5amjUd930lBpez6hmcngJTIpJoFYn297AkDSvo1odXVsRVKn IXlxCmxw6QupsoZOi114Q0rFiE68z+qshxd9UryDp1Pxlq4jdyK9Bv6S; X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Francois Audet wrote: > > > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Friday, October 27, 2006 4:20 PM >>To: Audet, Francois (SC100:3055) >>Cc: IETF SIP List >>Subject: Re: [Sip] RE: TLS meaning >> >>Francois Audet wrote: >> >> >> >>>Please calm down. >>> >>>Here is one simple scenario. >>> >>>I deploy an Enteprise SIP network. I install 10 SIP proxies >>> >>> >>accross the >> >> >>>Corporate Network. All the proxies are certified to properly >>> >>> >>implement >> >> >>>SIPS. All the phones are also certified to implement SIPS >>> >>> >>properly. I >> >> >>>know, because I am responsible for the network. >>> >>>An end user can call another end-user within that network with the >>>certitude that if sips is used, it will be secured end-to-end. >>> >>> >>> >>How about an example when it's not all within the same >>administrative entity. How abouts some examples that >>resemble, oh say, the mail system. >>These have always been where my concerns are. Within my own >>domain, I don't need SIPS; I can do that by executive fiat. >> >> > >In that case, if you don't have trust with them, then don't use >sips. As simple as that. > >Yes you need sips in your own domain, because some devices support TLS, >others don't. Some users want to be addressed securily, others don't. > > No. I do not require a signaling element to decide whether to route via SIP/TLS or just SIP. I can just as easily statically provision it. Or I can try it on a SIP/TLS listener port first. Or any other way to do the same thing. In any case, you didn't respond to my point that SIPS is not end to end security. That's just false on its face, and the seeming fact that you don't get the difference is the tip of a very problematic iceberg. 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 Oct 27 20:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmJ-0006Yd-Jp; Fri, 27 Oct 2006 20:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmH-0006Pb-Lg for sip@ietf.org; Fri, 27 Oct 2006 20:10:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdbl3-0005IW-R1 for sip@ietf.org; Fri, 27 Oct 2006 20:09:08 -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 k9S08wJ22332; Fri, 27 Oct 2006 20:08:58 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 19:08:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC29686@zrc2hxm0.corp.nortel.com> In-Reply-To: <4542971C.3080706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6IDccD/OBSwz3Shyz947x+eq7qwAA4iSw From: "Francois Audet" To: "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 =20 > No. I do not require a signaling element to decide whether to=20 > route via SIP/TLS or just SIP. I can just as easily=20 > statically provision it. Or I can try it on a SIP/TLS=20 > listener port first. Or any other way to do the same thing. You do if if it's the originator that wants to use TLS hop-by-hop. > In any case, you didn't respond to my point that SIPS is not=20 > end to end security. That's just false on its face, and the=20 > seeming fact that you don't get the difference is the tip of=20 > a very problematic iceberg. We all understand that sips is NOT an end-to-end security protocol, no need to insult people. In any case, what I haven't heard from you is a useful proposal on what you would actually do. We're just trying to deal with the cards we are given.=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 Oct 27 20:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdbna-0001Ez-R5; Fri, 27 Oct 2006 20:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmZ-00079B-Rg for sip@ietf.org; Fri, 27 Oct 2006 20:10:40 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdbXl-0004YG-Bo for sip@ietf.org; Fri, 27 Oct 2006 19:55:22 -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 k9RNmRw09320; Fri, 27 Oct 2006 19:48: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] RE: TLS meaning Date: Fri, 27 Oct 2006 18:55:12 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F4B261C@zrc2hxm2.corp.nortel.com> In-Reply-To: <86ejstjquf.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6Hsm17PafqvI+TE2jzju2XnLERwAA96eg From: "Samir Srivastava" To: "EKR" , "Michael Thomas" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ext Cullen Jennings , IETF SIP List , Francois Audet , "Peterson, Jon" , 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 Hello All, The better would have been similar to what was done in SNMP v2 and v3.=20 Instead of just filing the some text, as IESG required for the security considertation. Deprecate SIPS altogether.=20 Call SIP V2 as UNSECURE and Create SIP V3 with security, or use it with more elegant Proxy-Require/Require tag with my proposal. Thx SAmir > > So here we are, 5 years later. Boy oh boy, that big dollop of > > "security" that got > > thrown in at the last minute sure was a godsend. Heavens, what would we > have > > done without S/MIME and SIPS? Silly me to think that separating out > > the problems > > so they actually fit the requirements was a better plan. >=20 >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 27 20:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmQ-0006o9-1W; Fri, 27 Oct 2006 20:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmO-0006ag-VL for sip@ietf.org; Fri, 27 Oct 2006 20:10:28 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdbhk-00055L-UH for sip@ietf.org; Fri, 27 Oct 2006 20:05:42 -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 k9S057604969; Fri, 27 Oct 2006 20:05:07 -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] RE: TLS meaning Date: Fri, 27 Oct 2006 19:05:06 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F4B262A@zrc2hxm2.corp.nortel.com> In-Reply-To: <4542948F.8060004@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6Hr29vnZ61M4bSrOdiZPBbLNnvAABXGzg From: "Samir Srivastava" To: "Paul Kyzivat" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Joel M. Halpern" , 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 >=20 > Let me restate one question above because I think it might be a big deal: >=20 > How does SIPS work with B2BUAs/SBCs? Is it ok for an SBC to splice > together a SIPS call and a SIP call? Do anybody believe this won't happen? I asked the same question. And then our man came up, we don't want to state this. And even the quys from leading SBC vendor agreed that, we don't need it.. Great !! people don't want to know their own product requirement !!!! Thx Samir =20 >=20 > Paul >=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 Fri Oct 27 20:18:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdbs7-00008q-SP; Fri, 27 Oct 2006 20:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdbs6-00008J-R5 for sip@ietf.org; Fri, 27 Oct 2006 20:16:22 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdbs4-0006VR-HA for sip@ietf.org; Fri, 27 Oct 2006 20:16:22 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 9F1711E8C28; Fri, 27 Oct 2006 17:16:19 -0700 (PDT) To: "Samir Srivastava" Subject: Re: [Sip] RE: TLS meaning References: <62B9B0847CC47543B6B3B5E26BD268E60F4B261C@zrc2hxm2.corp.nortel.com> From: Eric Rescorla Date: Fri, 27 Oct 2006 17:16:19 -0700 In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F4B261C@zrc2hxm2.corp.nortel.com> (Samir Srivastava's message of "Fri, 27 Oct 2006 18:55:12 -0500") Message-ID: <86ac3hjnvw.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: ext Cullen Jennings , Michael Thomas , "Peterson, Jon" , IETF SIP List , Francois Audet , 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: > Hello All, > > The better would have been similar to what was done in SNMP v2 and > v3. > > Instead of just filing the some text, as IESG required for the security > considertation. Deprecate SIPS altogether. > > Call SIP V2 as UNSECURE and Create SIP V3 with security, or use it with > more elegant Proxy-Require/Require tag with my proposal. This assumes the exact point under discussion, namely that SIPS can't be made good enough. -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 Oct 27 20:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdc7P-0005t1-Mj; Fri, 27 Oct 2006 20:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdc7O-0005s5-4A for sip@ietf.org; Fri, 27 Oct 2006 20:32:10 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdc7M-0008DB-RT for sip@ietf.org; Fri, 27 Oct 2006 20:32:10 -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 k9S0P9V13460; Fri, 27 Oct 2006 20:25: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] RE: TLS meaning Date: Fri, 27 Oct 2006 19:31:54 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F4B2640@zrc2hxm2.corp.nortel.com> In-Reply-To: <86ac3hjnvw.fsf@raman.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb6Jk0u9bOEr7XXQsWfW1HL/vk35gAAYiGg From: "Samir Srivastava" To: "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ext Cullen Jennings , Michael Thomas , "Peterson, Jon" , IETF SIP List , Francois Audet , 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 Yes. Today's thread is converting into the another wacky thread. I am still going through with different person's arguments. Okay. how can I route telURI, urn etc over the SIP network securely with only SIPS even if I accept the known caveats of last hop exception, retargeting etc.. Thx Samir > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Friday, October 27, 2006 5:16 PM > To: Srivastava, Samir (SC100:8826) > Cc: Michael Thomas; ext Cullen Jennings; Peterson, Jon; IETF SIP List; > Audet, Francois (SC100:3055); Dean Willis > Subject: Re: [Sip] RE: TLS meaning >=20 > "Samir Srivastava" writes: >=20 > > Hello All, > > > > The better would have been similar to what was done in SNMP v2 and > > v3. > > > > Instead of just filing the some text, as IESG required for the security > > considertation. Deprecate SIPS altogether. > > > > Call SIP V2 as UNSECURE and Create SIP V3 with security, or use it with > > more elegant Proxy-Require/Require tag with my proposal. >=20 > This assumes the exact point under discussion, namely that SIPS can't > be made good enough. >=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 Fri Oct 27 20:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdcBB-0003Ad-Pu; Fri, 27 Oct 2006 20:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdcBA-0003AT-AI for sip@ietf.org; Fri, 27 Oct 2006 20:36:04 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdcB8-00008t-0b for sip@ietf.org; Fri, 27 Oct 2006 20:36:04 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 1CF4D3A02158; Fri, 27 Oct 2006 17:35:55 -0700 (PDT) Received: from [10.1.28.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id E0FFE3A02157; Fri, 27 Oct 2006 17:35:51 -0700 (PDT) Message-ID: <4542A5E7.3050809@acm.org> Date: Fri, 27 Oct 2006 17:35:51 -0700 From: Marc Petit-Huguenin User-Agent: Icedove 1.5.0.7 (X11/20061014) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Updated route construct specification References: <4535367D.6030707@cisco.com> In-Reply-To: <4535367D.6030707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 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 Hi Jonathan, It seems that the text for the 305 response disappeared between -01 and -02, but draft-rosenberg-sip-outbound-discovery-mid-dialog-00 is still using this reference. Is there a plan to move the 305 text to another I-D? Thanks. Jonathan Rosenberg wrote: > I've updated this document. It is (once again) almost completely > rewritten. Until it appears in the archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-02.txt > > Basically, it proposes to turn Service-Route into the inverse of Path, > so that Service-Route/Path work more like record-routing. This is now > specified in a way which is backwards compatible with IMS, which was an > issue for the previous spec. I believe this makes service-route usable > for the internet at large, and it is a key part of solving the > sip-outbound mid-dialog failover problem. Its also WAY simpler than > previous versions. The whole bit in there about redirections overriding > route sets is now folded into the more general UA loose routing document > I also published. > > Just to get some controversy thrown in there, the draft also specifies > as part of its behavior that a UA register only a single contact at a > time, and only that contact get reflected in the REGISTER response. > > Thanks, > Jonathan R. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [ RFC1855-compliant space for rent] Work: marc@8x8.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 Sat Oct 28 02:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhs2-0006i9-J1; Sat, 28 Oct 2006 02:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhrz-0006ek-S0 for sip@ietf.org; Sat, 28 Oct 2006 02:40:39 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdhry-0004Cl-GK for sip@ietf.org; Sat, 28 Oct 2006 02:40:39 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 3EBDBAC422; Sat, 28 Oct 2006 09:40:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17730.64352.150500.121670@harjus.tutpro.com> Date: Sat, 28 Oct 2006 09:40:32 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> References: <45428736.8070105@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Joel M. Halpern" , 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 Francois Audet writes: > You can NOT do that today without SIPS because there is no way > with SIP only to request that all hops be over TLS. you cannot do that today with SIPS either, because SIPS according to RFC3261 does NOT require that ALL hops are over TLS. and if you check the mailing list archives and even this present thread, you see that there is no agreement that SIPS MUST mean "ALL hops are over TLS". so i don't understand what you are talking about. -- 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 Sat Oct 28 02:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhtg-0001sQ-CG; Sat, 28 Oct 2006 02:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhte-0001s7-Fo for sip@ietf.org; Sat, 28 Oct 2006 02:42:22 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdhtd-0004Vp-4q for sip@ietf.org; Sat, 28 Oct 2006 02:42:22 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 6A8FDAC422; Sat, 28 Oct 2006 09:42:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17730.64460.376775.928040@harjus.tutpro.com> Date: Sat, 28 Oct 2006 09:42:20 +0300 To: "Joel M. Halpern" Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Joel M. Halpern writes: > And it seems to me that the user is getting what he wants when he > uses it. yes, but has no way of knowing for sure what he gets. -- 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 Sat Oct 28 02:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhs2-0006i9-J1; Sat, 28 Oct 2006 02:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhrz-0006ek-S0 for sip@ietf.org; Sat, 28 Oct 2006 02:40:39 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdhry-0004Cl-GK for sip@ietf.org; Sat, 28 Oct 2006 02:40:39 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 3EBDBAC422; Sat, 28 Oct 2006 09:40:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17730.64352.150500.121670@harjus.tutpro.com> Date: Sat, 28 Oct 2006 09:40:32 +0300 To: "Francois Audet" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> References: <45428736.8070105@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DC295EB@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Joel M. Halpern" , 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 Francois Audet writes: > You can NOT do that today without SIPS because there is no way > with SIP only to request that all hops be over TLS. you cannot do that today with SIPS either, because SIPS according to RFC3261 does NOT require that ALL hops are over TLS. and if you check the mailing list archives and even this present thread, you see that there is no agreement that SIPS MUST mean "ALL hops are over TLS". so i don't understand what you are talking about. -- 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 Sat Oct 28 02:45:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhtg-0001sQ-CG; Sat, 28 Oct 2006 02:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdhte-0001s7-Fo for sip@ietf.org; Sat, 28 Oct 2006 02:42:22 -0400 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdhtd-0004Vp-4q for sip@ietf.org; Sat, 28 Oct 2006 02:42:22 -0400 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 6A8FDAC422; Sat, 28 Oct 2006 09:42:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17730.64460.376775.928040@harjus.tutpro.com> Date: Sat, 28 Oct 2006 09:42:20 +0300 To: "Joel M. Halpern" Subject: Re: [Sip] RE: TLS meaning In-Reply-To: <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> References: <45415267.7000905@cisco.com> <063801c6f9c4$9630e1d0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061027113427.034ae1b8@stevecrocker.com> <861wotoj59.fsf@raman.networkresonance.com> <89E8CEFF-452B-46B4-B2BD-D2EB26F48667@softarmor.com> <864ptpn1xw.fsf@raman.networkresonance.com> <9D9BEE85-743A-422A-8212-4B761AF3809B@softarmor.com> <7.0.1.0.0.20061027183322.034a4bd0@stevecrocker.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Joel M. Halpern writes: > And it seems to me that the user is getting what he wants when he > uses it. yes, but has no way of knowing for sure what he gets. -- 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 Sat Oct 28 05:30:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkSr-0001V0-9f; Sat, 28 Oct 2006 05:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkSp-0001Rl-5M for sip@ietf.org; Sat, 28 Oct 2006 05:26:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdkSg-0003sd-4B for sip@ietf.org; Sat, 28 Oct 2006 05:26:51 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 397DB6E1; Sat, 28 Oct 2006 11:26:37 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 11:26:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 11:26:36 +0200 Received: from [131.160.126.5] (rvi2-126-5.lmf.ericsson.se [131.160.126.5]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 42F9B232A; Sat, 28 Oct 2006 12:26:36 +0300 (EEST) Message-ID: <4543224A.1040401@ericsson.com> Date: Sat, 28 Oct 2006 12:26:34 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Help: About Early-Session and Session References: <4540BAB0.9060503@cisco.com> In-Reply-To: <4540BAB0.9060503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2006 09:26:36.0817 (UTC) FILETIME=[2A84D810:01C6FA73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, zhang.lu2@zte.com.cn X-BeenThere: sip@ietf.org X-Mailman-Version: 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, some folks told me offline that they were going to implement this, but I did not hear from them after that. Giving the level of early-media-related discussions we are having lately, it is obvious that people are still looking for new mechanisms to handle early media. Cheers, Gonzalo Paul Kyzivat wrote: > > > zhang.lu2@zte.com.cn wrote: >> >> Dear Sip Group, >> >> There encounters a question when I read RFC 3959 and RFC 3960 >> which refer to the Early-Session , that is >> "Does Offer/Answer Model defined in RFC 3264 apply to >> Early-Session and Session independently?" > > There has been little to no discussion of this. All the extensive and > detailed investigation of offer/answer, including the offeranswer draft, > have avoided this subject. > > But IMO if the application server model is followed, using the > early-session disposition, then indeed the session and early-session > must independently follow the offer/answer model. > > This can potentially lead to some very complex interactions. For > instance, the caller could make a offer for the session, and the callee > could make an early-session offer in the other direction. Then they both > could use preconditions that result in further offers and answers for > both session and early-session as those are resolved. Each would > presumably be required to follow the rules about only one offer or > answer per transaction, but a single transaction might carry an offer or > answer for each of session and early-session. > > I'm not aware of anyone having attempted an implementation of this. If > somebody has, please speak up. (Copying Gonzalo since he is author and > might know of an implementation, and Robert in case this has ever come > up at SIPit.) > > IMO its extremely unlikely that this will ever be implemented well > enough (if at all) to achieve interoperability. There is enough trouble > getting basic offer/answer working. > > Paul > > >> In RFC 3959 section 7, there is a example as below: >> A B >> | | >> |--------(1) INVITE-------->| >> | offer | >> | | >> |<--(2) Session Progress----| >> | early-offer | >> | answer | >> | | >> |---------(3) PRACK-------->| >> | early-answer | >> | | >> |<--------(4) 200 OK--------| >> | | >> | * * | >> | ************************* | >> |* Early Media *| >> | ************************* | >> | * * | >> | | >> |<--------(5) 200 OK--------| >> | | >> |----------(6) ACK--------->| >> | | >> >> Figure 1: Message flow >> >> Hope to have a letter from you soon. >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >> mail is solely property of the sender's organization. This mail >> communication is confidential. Recipients named above are obligated to >> maintain secrecy and are not permitted to disclose the contents of >> this communication to others. >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error please notify >> the originator of the message. Any views expressed in this message are >> those of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam >> system. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 28 08:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdni0-0008Hg-Vo; Sat, 28 Oct 2006 08:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdnhd-0007p0-EN for sip@ietf.org; Sat, 28 Oct 2006 08:54:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdnX9-0004xn-9l for sip@ietf.org; Sat, 28 Oct 2006 08:43:32 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2006 05:43:30 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9SChU5e008860; Sat, 28 Oct 2006 05:43:30 -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 k9SChUin017716; Sat, 28 Oct 2006 05:43:30 -0700 (PDT) Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9SCUoTq009946; Sat, 28 Oct 2006 05:30:50 -0700 In-Reply-To: <45428736.8070105@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> <45428736.8070105@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64C7A567-78FA-4A1F-9E96-E9320031B173@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] RE: TLS meaning Date: Sat, 28 Oct 2006 08:43:21 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.2) Authentication-Results: sj-dkim-4.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=4498; t=1162039410; x=1162903410; c=relaxed/simple; s=sjdkim4002; 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]=20RE=3A=20TLS=20meaning; X=v=3Dcisco.com=3B=20h=3DA7ttCP2aQ62DFLDo2VT0XPKpLOc=3D; b=lwgNo1so4IjHe0iS2bc6b2vPU8HHP5wFeL8Qwvx3F1Wez5I4+vGTQkxZzd9bWxnaygbQknwA vyB4Djs6nu/rnQy8d7H+tGwt3PdTSGRH4zIiOogT5PFQbtymNBPj8HzN; X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , 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 Sorry to jump into the middle of the thread, but given the long chain, I had to pick somewhere to insert my personal opinion. I'll note that I'm one of the guilty parties in raising the whole question about the utility of sips, so I guess I ought to support some way forward here. There was a suggestion earlier in the thread I really liked, which I think was: a) get rid of sips as a url scheme. b) write a BCP which says if you get TLS in, send TLS out. In what way does this not give us EXACTLY the capability we have with SIPS, without all the complexity of a separate url scheme and the semantic mismatch problems people (including me) keep hammering on when we compare sips to https. Dave Oran. On Oct 27, 2006, at 6:24 PM, Paul Kyzivat wrote: > > > Francois Audet wrote: >> The practical use is to be able to deploy hop-by-hop TLS-based SIP >> signalling (using transitive trust), with the current RFC 3261 >> complemented with the explanation of my draft, in the SHORT TERM. > > The problem I have with this is that it takes us from "the emperor > is naked" to "the emperor is in his underwear". > > If you take a system built using SIP over UDP, and upgrade it to > SIPS, what can you now put in your sales brochure that you couldn't > put before? > > Apparently you can't now advertise "secure calling" or put a little > lock icon on the display. All you can say is "we don't suck as bad > as we used to". and you probably can't even realize this level of > improvement on all calls. You still must be prepared for cases > where you can't get SIPS. So I guess the claim must be "we don't > suck as bad as we used to, on some calls". Maybe we could put a > little "half ass" icon up when the call is via SIPS. > > How much extra investment does that justify? > > It seems like the best we could do is start deploying SIPS as a > hidden cost of doing business, to try to get closer to what most > customers no doubt assume is already there. But unless it is done > quite ubiquitously it won't even help reduce the possibility of > some really bad exploit happening. > > Paul > >> I.e., without waiting for SIP to develop the next protocol that >> allows for other alternative security mechanisms. >> You have to understand that people ARE implementing sips today >> because >> of market demand. They won't stop doing this because we promise them >> that a few years from now, we'll have something better. >> I'd much rather have implementations that follow our recommendations >> on that front, rather than have vastly different intrepretation of >> RFC 3261's SIPS. If we don't have practical guidelines for the >> current >> state of the art, that's exactly what will happen. >> I don't believe any of us is arguing that sips is the greatest thing >> since slice bread. I don't think any of us is arguing that it is >> unreasonable to use other protocols for securing SIP either (although >> there is a split of opinions on if that should be called sips or >> not). >> We are just saying that sips can relatively easily be made to work >> for hop-by-hop TLS, in the short term. >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, >>> October 27, 2006 1:34 PM >>> To: Audet, Francois (SC100:3055) >>> Cc: Brian Rosen; Dean Willis; Joel M. Halpern; IETF SIP List >>> Subject: Re: [Sip] RE: TLS meaning >>> >>> Note that my comment and Brian's initial one on the same subject >>> were independently and simultaneously created. As soon as I saw >>> Brian's comment I knew he would be replying back to me. >>> >>> I don't dispute that making the necessary specifications will be >>> hard. I don't know if it would be useful to attach the SIPS name >>> to this new thing or not. It may be that some other way (e.g. >>> Proxy-Require) would be better. Or maybe a scheme name, SIPS or >>> something else, would really be good for it. >>> >>> But I'm so far not convinced that an all-TLS-based SIPS actually >>> delivers anything that has a practical use. >>> >>> 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 Sat Oct 28 09:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPy-0003Lt-C8; Sat, 28 Oct 2006 09:40:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdoPm-0003F2-AH for sip@ietf.org; Sat, 28 Oct 2006 09:39:58 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdoK5-0002gR-Cn for sip@ietf.org; Sat, 28 Oct 2006 09:34:06 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 48D831E8C28; Sat, 28 Oct 2006 06:34:04 -0700 (PDT) To: David R Oran Subject: Re: [Sip] RE: TLS meaning References: <1ECE0EB50388174790F9694F77522CCF0DC2944F@zrc2hxm0.corp.nortel.com> <45428736.8070105@cisco.com> <64C7A567-78FA-4A1F-9E96-E9320031B173@cisco.com> From: Eric Rescorla Date: Sat, 28 Oct 2006 06:34:04 -0700 In-Reply-To: <64C7A567-78FA-4A1F-9E96-E9320031B173@cisco.com> (David R. Oran's message of "Sat, 28 Oct 2006 08:43:21 -0400") Message-ID: <864ptok1ir.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: c1c65599517f9ac32519d043c37c5336 Cc: "Joel M. Halpern" , IETF SIP List , Paul Kyzivat , Francois Audet , 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 David R Oran writes: > Sorry to jump into the middle of the thread, but given the long > chain, I had to pick somewhere to insert my personal opinion. I'll > note that I'm one of the guilty parties in raising the whole question > about the utility of sips, so I guess I ought to support some way > forward here. There was a suggestion earlier in the thread I really > liked, which I think was: > > a) get rid of sips as a url scheme. > b) write a BCP which says if you get TLS in, send TLS out. > > In what way does this not give us EXACTLY the capability we have with > SIPS, without all the complexity of a separate url scheme and the > semantic mismatch problems people (including me) keep hammering on > when we compare sips to https. And what if you can't send TLS out because the other side doesn't support it? If you go ahead and proceed with SIP in the clear, then you've introduced an active attack problem (downgrade attack). If you fail, then you've disincentivized people from securing *any* link with TLS because it may cause their calls to fail. This is an especially serious issue with long-term connections like outbound encourages. >From a security perspective, SIPS has two important properties: 1. It says to the client "you MUST talk to me over SSL". 2. It says to the proxies "I expect you to make the outgoing connection with TLS". As Samir has observed, the second property can be provided with some indicator in the SIP header. However, the first can only be provided by putting the indicator in the reference which you hand around (i.e., the SIP URI). This isn't to say it necessarily has to be a new URI scheme--though it did in HTTP because HTTP doesn't have parameters--but it's not clear to me that moving it to parameters would really help. -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 akstcgatenbysandersonmnsdgs@gatenbysanderson.com Sat Oct 28 11:29:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdq7S-0007MG-V5 for sip-archive@lists.ietf.org; Sat, 28 Oct 2006 11:29:10 -0400 Received: from [61.47.97.196] (helo=cluster4a.us.messagelabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdq7R-00050S-CJ for sip-archive@lists.ietf.org; Sat, 28 Oct 2006 11:29:10 -0400 Received: from 85.158.137.35 (HELO cluster3.eu.messagelabs.com) by lists.ietf.org with esmtp (TX5E3H95 1HK4M0) id C7QODW-1KAUYM-8C for sip-archive@lists.ietf.org; Sat, 28 Nov 2006 15:29:09 -0420 From: "Van Helton" To: Subject: milk-livered music paper Date: Sat, 28 Nov 2006 15:29:09 -0420 Message-ID: <01c6faa5$d03f6040$6c822ecf@akstcgatenbysandersonmnsdgs> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 cannot always be within doors; and in the nearness of the parsonage, or the pleasantness of the walk to From sip-bounces@ietf.org Sat Oct 28 11:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdqKW-0007fS-5v; Sat, 28 Oct 2006 11:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdqKU-0007Zd-T6 for sip@ietf.org; Sat, 28 Oct 2006 11:42:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdqKS-0006sg-4p for sip@ietf.org; Sat, 28 Oct 2006 11:42:38 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2006 08:42:36 -0700 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 k9SFgZXL019117; Sat, 28 Oct 2006 08:42:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9SFgPOX017847; Sat, 28 Oct 2006 08:42:29 -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); Sat, 28 Oct 2006 08:42:27 -0700 Received: from [192.168.1.3] ([10.21.98.204]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Oct 2006 08:42:26 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266709F22FA1@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266709F22FA1@ntht201e.siemenscomms.co.uk> 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 Date: Sat, 28 Oct 2006 08:42:28 -0700 To: "Elwell, John" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Oct 2006 15:42:27.0206 (UTC) FILETIME=[AB992260:01C6FAA7] DKIM-Signature: a=rsa-sha1; q=dns; l=10738; t=1162050155; x=1162914155; 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=20Rejecting=20connected=20identity=20(was=20RE=3A=20draft-ietf-sip -connecte=09d-id=20entity-01=20comments); X=v=3Dcisco.com=3B=20h=3D9c4IiWPZSyHOezmVLKVYjYllBX8=3D; b=NHxGCod2HBObqaEMFFZMAQ5Imm9VCypjC8NbLwZBILNU8YO5aSGGHF5t/EK/jzMw+2m4XDwD by9ogCtOIWBcQo2VEsG1NvV5ea/5eD7LteGGC582vNPrM03nGGPSIYVS; 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: a4cdc653ecdd96665f2aa1c1af034c9e Cc: SIP , Paul Kyzivat , Jon Peterson Subject: [Sip] Re: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 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 This is clearly hard and I would like to talk about it in person and see if we can sort it out. A few things I was thinking about ... a) are there any practical scenarios where the initial invite identity would have worked then the later mid dialog one fails in this way b) If the authentication verification fails and I have an authorization policy at proxy that says don't accept unverified calls, then clearly it needs to fail - even if it is retried c) should we consider something like, in the case of an error like this, a UA could retry as an anonymous call Let's talk in San Diego... On Sep 26, 2006, at 1:02 PM, Elwell, John wrote: > Cullen, Jon, > > In case you missed this (it wasn't addressed directly to you), I would > greatly appreciate an opinion from each of you on this remaining > issue in > connected-identity. Just to summarise, RFC 4474 leaves it up to policy > whether to return a 428 response if Identity is missing, but > mandates the > sending of a 436, 437 or 438 response for certain errors arising while > verifying the signature. It seems that for mid dialog requests this > behaviour could be harmful. What does the UAC for the mid dialog > request do > if it receives 436, 437 or 438? If the mid-dialog request was > solely for the > purpose of connected identity, it can give up and allow the call to > continue > as is. But if the request was for some other purpose (e.g., > renegotiating > the session because of hold, say, or session timer refresh), the > UAC really > wants it to work. For the normal case where the Authentication > Service is at > a proxy, not at the UAC, the UAC cannot force the Authentication > Service to > refrain from putting this unverifiable signature in the mid-dialog > request, > so any attempts to repeat the request would most likely be doomed > to getting > the same response. > > It seems there are three things we could do, none very attractive: > 1. Get connected-identity to modify the procedures of RFC 4474 for a > verifier by softening the requirements for sending 436, 437 and 438 in > response to mid-dialog requests. But then a mid-dialog request from > a rogue > source would be accepted. > 2. Say that the Authentication Service should omit the signing of > mid-dialog > requests if a previous attempt has resulted in 436, 437 or 438. But > this > implies statefulness at the AS. > 3. Accept the fact the mid-dialog requests can fail in this way and > therefore things like session refresh and session renegotiation > cannot be > done, probably resulting in call failure. Sounds bad, but it is no > different > from an initial INVITE request, where there is nothing the UAC can > do if the > AS inserts an Identity header that gets rejected with 436, 437 or 438. > > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 22 September 2006 19:26 >> To: Elwell, John >> Cc: Cullen Jennings; SIP >> Subject: Re: Rejecting connected identity (was RE: >> draft-ietf-sip-connected-id entity-01 comments) >> >> John, >> >> I want to hear what others, especially Jon and Cullen, have >> to say about >> this. >> >> It is of some concern to me that a call might fail because of some >> problem with the identity mechanism when the same call might have >> succeeded in the absence of any identity. >> >> But possibly the solution to this is policy in the >> implementation of the >> verifier. What to do in the case of the conditions that lead to these >> errors could be configurable in the verifier: either to generate the >> error or simply to remove the identity info from the message. And the >> policy could conceivably vary based on attributes of the >> message, such >> as whether it is in-dialog or not. >> >> Does it require a change to 4474 to permit that kind of policy? >> >> It would be annoying if the end user had no control over the >> insertion >> and verification of identity, and it resulted in calls >> failing that the >> user would like to permit. But I suppose that is itself a policy >> decision. There are certainly enterprises that want to exert >> that kind >> of control over what users are permitted to do. >> >> Paul >> >> Elwell, John wrote: >>> Paul, >>> >>> I agree with most of your points, and on reflection I think >> I agree that the >>> solution has to be with the verifier. >>> >>> I think RFC 4474 is not a problem as far as sending a 428 >> 'Use Identity >>> Header' response is concerned, because that is left to >> policy, so we could >>> say in connected-identity that policy should be to not send 428. >>> >>> However, 436, 437 and 438 responses are all a problem, >> because RFC 4474 says >>> that they MUST be sent under respective conditions. >> Interestingly, though, >>> there are other failure scenarios that can arise from the >> procedures of >>> section 6 of RFC 4474 for which no normative statement is >> given on how to >>> respond, e.g. invalid Date header field, signer not >> authoritative for the >>> domain. >>> >>> So one way to solve the present problem would be for the >> connected-identity >>> draft to modify verifier behaviour in RFC 4474 in the case >> of mid-dialog >>> requests. I guess this would mean that it would update RFC >> 4474 as well as >>> updating RFC 3261. But I don't like this, because it seems >> to remove some of >>> the security properties of RFC 4474. >>> >>> Another way would be to accept that 436, 437 and 438 >> responses will be sent, >>> and failure to verify a signature will therefore result in >> inability to >>> process the UPDATE or re-INVITE request, and hence if the UPDATE or >>> re-INVITE request was for some other purpose such as >> session timer refresh >>> or modifying the session, that action will fail. Then the >> call will fail (in >>> the case of inability to refresh the session timer) or the session >>> modification will fail. I guess this is somewhat analogous >> to caller ID >>> verification failure in an INVITE request - it is >> impossible to establish a >>> call if verification fails. Moreover, the UAC has no >> ability to rectify the >>> situation, since it is at the mercy of a proxy-based >> Authentication Service >>> that puts a rogue Identity header field in every request. >> In the connected >>> identity case, the only difference is that the call is >> already established >>> but is likely to fail if verification fails. >>> >>> Of course, if the mid-dialog request is indeed from the >> wrong source, then >>> sending a 436, 437 or 438 response is indeed the correct >> thing to do, and >>> overriding the verification procedures of RFC 4474 would >> indeed be the wrong >>> thing to do. So perhaps we just have to accept that these >> response codes can >>> be received and will lead to failure. >>> >>> So, my preferred way forward is simply to recommend not >> sending a 428 and >>> accept the consequences of other responses that the >> verifier might send. >>> >>> John >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 22 September 2006 15:13 >>>> To: Elwell, John >>>> Cc: Cullen Jennings; SIP >>>> Subject: Re: [Sip] RE: >> draft-ietf-sip-connected-identity-01 comments >>>> >>>> >>>> >>>> Elwell, John wrote: >>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> When an Update is sent. Are there any conditions under which >>>>>> it might >>>>>> be rejected. Bad identity for example. I think that >> might need a >>>>>> little discussion and also what the UA does when it sends >>>> an update >>>>>> with a no identity and it gets rejected. >>>>> [JRE] A very good point. We don't want to get to a >>>> situation where it is >>>>> impossible to perform a mid-dialog request (e.g., for >>>> purposes such as >>>>> session timer refresh or session re-negotiation) just >>>> because connected >>>>> identity fails. >>>>> My proposed fix is as follows: >>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request >>>> with 428 'Use >>>>> Identity Header'. >>>> I'm not sure about this. At the least I think this one needs >>>> some clear >>>> explanation of the SHOULD NOT - about the conditions when >> it can be >>>> violated. >>>> >>>> I see this as somewhat analogous to doing a digest challenge on an >>>> in-dialog request. In some cases it is the right thing to do. >>>> >>>> A UA that imposes such a requirement will be limited in what >>>> it can do, >>>> but that may still be right in some cases. >>>> >>>>> 2. Say that an Authentication Service MUST NOT add an >>>> Identity header field >>>>> to a mid-dialog request if a previous request on that >>>> dialog has resulted in >>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or >>>> 438 'Invalid >>>>> Identity Header'. >>>> This requirement would force the authentication service to >> be dialog >>>> stateful, which is not ideal. Better to push the state >> back into the >>>> sender of the request. This may require a way for the UAC >> to tell the >>>> authentication service not to act. >>>> >>>>> 3. Say that a UAC MUST repeat a mid-dialog request that >>>> results in one of >>>>> these responses if the mid-dialog request was not solely >>>> for the purpose of >>>>> connected identity. If solely for the purpose of connected >>>> identity there is >>>>> no point in repeating it, so I will say "SHOULD NOT take >> any further >>>>> action". >>>> This seems wrong to me. >>>> >>>> I think that the remedy to these is in the verifier. The >>>> purpose of the >>>> verifier is ultimately to drive an authorization decision. If >>>> authorization would succeed in the absence of the >> identity, then the >>>> request should be permitted to continue as if the identity >>>> was not present. >>>> >>>> Unfortunately this would seem to require a revision to 4474 >>>> even though >>>> the paint is hardly dry on it. >>>> >>>> If this is done, then there is no need of a mechanism to cause the >>>> authentication service *not* to authenticate. If this is >> *not* done, >>>> then that need remains, which will still require a change to 4474. >>>> >>>> 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 Sat Oct 28 12:06:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdqfO-0006hx-Kk; Sat, 28 Oct 2006 12:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdqef-0005eA-Bo for sip@ietf.org; Sat, 28 Oct 2006 12:03:29 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdqWc-00004u-AE for sip@ietf.org; Sat, 28 Oct 2006 11:55:12 -0400 Received: (qmail 32163 invoked by uid 0); 28 Oct 2006 15:56:09 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 28 Oct 2006 15:56:09 -0000 Message-ID: <007001c6faa9$6a1c1480$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" Date: Sat, 28 Oct 2006 17:54:55 +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: 1676547e4f33b5e63227e9c02bd359e3 Cc: sip@ietf.org Subject: [Sip] mid-dialog failover: need URI parameter for reg-id to avoid triangular routing X-BeenThere: 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="===============1139865801==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1139865801== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C6FABA.2D693B10" This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C6FABA.2D693B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jonathan, Regarding your outbound-discovery-mid-dialog draft: I believe it can work, but the example given in section 15 has some glitches and may result in sub-optimal routing. The backup flow from the UA x should have a different reg-id, say reg-id=*2* (instead of 1 as per the example in the draft). Assume there is also a user y registered, via proxy 1 and proxy 3. Then the connection table at the home proxy would look like TLS connection to 1: sip:outbound.example.com sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=stun TLS connection to 2: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=stun TLS connection to 3: sip:outbound.example.com sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=stun sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=stun Consequently, when proxy 2 fails, there will be no "most specific" match for message 35, only least specific ones. The request should go to proxy 3, but the home proxy could equally likely select proxy 1 (which would then perform triangular routing via proxy 2). To have the home proxy favor proxy 3 in this scenario, I believe we need a URI parameter to hold the reg-id, instead of putting it in the user part. If we would then define that flow selection should be performed based on the URI from which the reg-id parameter is stripped, there would be a partly specific match for proxy 3 and failover would work more smoothly Regards, Jeroen ------=_NextPart_000_006C_01C6FABA.2D693B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jonathan,
 
Regarding your = outbound-discovery-mid-dialog draft:=20 I believe it can work, but the example given in section 15 has some = glitches and=20 may result in sub-optimal routing.
 
The backup flow from the UA x should = have a=20 different reg-id, say reg-id=3D*2* (instead of 1 as per the example in = the draft).=20 Assume there is also a user y registered, via proxy 1 and proxy 3. = Then the connection table at the home proxy would = look=20 like
 
TLS connection to = 1:
   =20 sip:outbound.example.com
   =20 sip:proxy1+proxy3+y+instanceID+y1@outbound.example.com;keepalive=3Dstun

TLS connection to 2:
   =20 sip:outbound.example.com
   =20 sip:proxy2+proxy3+x+instanceID+1@outbound.example.com;keepalive=3Dstun
 
TLS connection to = 3:
   =20 sip:outbound.example.com
   =20 sip:proxy2+proxy3+x+instanceID+*2*@outbound.example.com;keepalive=3Dstun<= /FONT>
   =20 sip:proxy1+proxy3+y+instanceID+*y2*@outbound.example.com;keepalive=3Dstun=
 
Consequently, when proxy 2 fails, there = will be no=20 "most specific" match for message 35, only least specific ones. The = request=20 should go to proxy 3, but the home proxy could equally likely select = proxy 1=20 (which would then perform triangular routing via proxy 2).
 
To have the home proxy favor proxy 3 in = this=20 scenario, I believe we need a URI parameter to hold the reg-id, instead = of=20 putting it in the user part. If we would then define that flow selection = should=20 be performed based on the URI from which the reg-id parameter is = stripped, there=20 would be a partly specific match for proxy 3 and failover would work = more=20 smoothly
 
Regards,
Jeroen
------=_NextPart_000_006C_01C6FABA.2D693B10-- --===============1139865801== 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 --===============1139865801==-- From sip-bounces@ietf.org Sat Oct 28 15:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdtlv-0005t4-Gs; Sat, 28 Oct 2006 15:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdtlt-0005st-DB for sip@ietf.org; Sat, 28 Oct 2006 15:23:09 -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 1Gdtls-0006Av-4Q for sip@ietf.org; Sat, 28 Oct 2006 15:23:09 -0400 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AE0505E4; Sat, 28 Oct 2006 15:22:45 -0400 From: "Hadriel Kaplan" To: "'Samir Srivastava'" , "'Paul Kyzivat'" , "'Francois Audet'" Subject: RE: [Sip] RE: TLS meaning Date: Sat, 28 Oct 2006 15:22:34 -0400 Message-ID: <002601c6fac6$6c237710$0500a8c0@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: <62B9B0847CC47543B6B3B5E26BD268E60F4B262A@zrc2hxm2.corp.nortel.com> Thread-Index: Acb6Hr29vnZ61M4bSrOdiZPBbLNnvAABXGzgACge/VA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'Joel M. Halpern'" , '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 > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > > Let me restate one question above because I think it might be a big > deal: > > > > How does SIPS work with B2BUAs/SBCs? Is it ok for an SBC to splice > > together a SIPS call and a SIP call? Do anybody believe this won't > happen? > > I asked the same question. And then our man came up, we don't want to > state this. And even the quys from leading SBC vendor agreed that, we > don't need it.. Great !! people don't want to know their own product > requirement !!!! I not sure if you're referring to me - I speak for myself on this list, not my company. My company is fine with SIPS, and with your proposal for a proxy-require to specify the key size and such. In fact, my company would probably profit if such were used more often. You can probably guess why they would be more profitable if UAs started using such mechanisms. It's for the reasons I argued against such mechanisms. -hadriel p.s. and I think I do know my product requirements. It's my job to know them, and I tend to be right more often than 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 Sat Oct 28 23:07:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge0wR-00029E-TV; Sat, 28 Oct 2006 23:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge0pn-00064I-2m for sip@ietf.org; Sat, 28 Oct 2006 22:55:39 -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 1Ge0pl-0001c0-PP for sip@ietf.org; Sat, 28 Oct 2006 22:55:39 -0400 Received: from PKumar [10.0.200.105] by acmepacket.com with ESMTP (SMTPD-9.10) id A80F0630; Sat, 28 Oct 2006 22:55:11 -0400 From: "Prashant Kumar" To: "'Hadriel Kaplan'" , "'Samir Srivastava'" , "'Paul Kyzivat'" , "'Francois Audet'" Subject: RE: [Sip] RE: TLS meaning Date: Sat, 28 Oct 2006 22:55:11 -0400 Message-ID: <013101c6fb05$a6d234c0$800101df@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 In-Reply-To: <002601c6fac6$6c237710$0500a8c0@acmepacket.com> Thread-Index: Acb6Hr29vnZ61M4bSrOdiZPBbLNnvAABXGzgACge/VAAD94u4A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "'Joel M. Halpern'" , '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 I assume according to RFC3261, SIPS indicates that you should send over a secure channel. The secure channel could be TLS, IPSEC or any other means the provider thinks it is secure. I am not sure why people are trying to associate SIPS with https and TLS even though the original intention may be was that. I am not understanding the significance of this discussion. However, in any case downgrading from SIPS URI to a SIP URI does not look like a good idea since the "secure" assurance provided by a SIPS will be lost in that case! Regards, Prashant. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Saturday, October 28, 2006 3:23 PM To: 'Samir Srivastava'; 'Paul Kyzivat'; 'Francois Audet' Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Dean Willis' Subject: RE: [Sip] RE: TLS meaning > -----Original Message----- > From: Samir Srivastava [mailto:samirsr@nortel.com] > > > > Let me restate one question above because I think it might be a big > deal: > > > > How does SIPS work with B2BUAs/SBCs? Is it ok for an SBC to splice > > together a SIPS call and a SIP call? Do anybody believe this won't > happen? > > I asked the same question. And then our man came up, we don't want to > state this. And even the quys from leading SBC vendor agreed that, we > don't need it.. Great !! people don't want to know their own product > requirement !!!! I not sure if you're referring to me - I speak for myself on this list, not my company. My company is fine with SIPS, and with your proposal for a proxy-require to specify the key size and such. In fact, my company would probably profit if such were used more often. You can probably guess why they would be more profitable if UAs started using such mechanisms. It's for the reasons I argued against such mechanisms. -hadriel p.s. and I think I do know my product requirements. It's my job to know them, and I tend to be right more often than 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 29 00:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge2PL-0004J2-UF; Sun, 29 Oct 2006 00:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge2PL-0004Iu-6s for sip@ietf.org; Sun, 29 Oct 2006 00:36:27 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge2PJ-00082c-Te for sip@ietf.org; Sun, 29 Oct 2006 00:36:27 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E4ADC1E8C28; Sat, 28 Oct 2006 21:36:22 -0700 (PDT) To: "Prashant Kumar" Subject: Re: [Sip] RE: TLS meaning References: <013101c6fb05$a6d234c0$800101df@acmepacket.com> From: Eric Rescorla Date: Sat, 28 Oct 2006 21:36:22 -0700 In-Reply-To: <013101c6fb05$a6d234c0$800101df@acmepacket.com> (Prashant Kumar's message of "Sat, 28 Oct 2006 22:55:11 -0400") Message-ID: <86bqnvivqx.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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "'Joel M. Halpern'" , 'Francois Audet' , 'IETF SIP List' , 'Dean Willis' , '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 "Prashant Kumar" writes: > I assume according to RFC3261, SIPS indicates that you should send over a > secure channel. The secure channel could be TLS, IPSEC or any other means > the provider thinks it is secure. I am not sure why people are trying to > associate SIPS with https and TLS even though the original intention may be > was that. As previously noted, the security properties of these mechanisms aren't identical, so it doesn't preserve the UAC's intentions to use whatever means the provider thinks are secure. -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 Sun Oct 29 04:46:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge7Ah-0003Ru-BM; Sun, 29 Oct 2006 04:41:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge7Af-0003Rp-Vz for sip@ietf.org; Sun, 29 Oct 2006 04:41:37 -0500 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 1Ge7Ae-0003Sb-8M for sip@ietf.org; Sun, 29 Oct 2006 04:41:37 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7W0027T5LMM0@siemenscomms.co.uk> for sip@ietf.org; Sun, 29 Oct 2006 09:41:47 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZ4RC>; Sun, 29 Oct 2006 09:41:35 +0000 Content-return: allowed Date: Sun, 29 Oct 2006 09:41:34 +0000 From: "Elwell, John" To: Cullen Jennings Message-id: <50B1CBA96870A34799A506B2313F26670A38D725@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: 3b8eea209b62bd15620865bc4fbef8cd Cc: SIP , Paul Kyzivat , Jon Peterson Subject: [Sip] RE: Rejecting connected identity (was RE: draft-ietf-sip-connecte d-id entity-01 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 Cullen, See below. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 28 October 2006 16:42 > To: Elwell, John > Cc: Jon Peterson; SIP; Paul Kyzivat > Subject: Re: Rejecting connected identity (was RE: > draft-ietf-sip-connecte d-id entity-01 comments) > > > This is clearly hard and I would like to talk about it in person and > see if we can sort it out. A few things I was thinking about ... > > a) are there any practical scenarios where the initial invite > identity would have worked then the later mid dialog one fails in > this way [JRE] Yes, the initial mid-dialog request will be in the reverse direction, so a different Authentication Service and a different Verifier. > > b) If the authentication verification fails and I have an > authorization policy at proxy that says don't accept unverified > calls, then clearly it needs to fail - even if it is retried [JRE] Agreed. > > c) should we consider something like, in the case of an error like > this, a UA could retry as an anonymous call [JRE] I guess the UAC would need to use anonymous.invalid - then I think it could work. Using anonymous@example.com would not work, since a proxy-located Authentication Service for example.com might still add an Identity header field. > > Let's talk in San Diego... [JRE] Yes, indeed, we should try to chat before the SIP session, which fortunately is late in the week. > > On Sep 26, 2006, at 1:02 PM, Elwell, John wrote: > > > Cullen, Jon, > > > > In case you missed this (it wasn't addressed directly to > you), I would > > greatly appreciate an opinion from each of you on this remaining > > issue in > > connected-identity. Just to summarise, RFC 4474 leaves it > up to policy > > whether to return a 428 response if Identity is missing, but > > mandates the > > sending of a 436, 437 or 438 response for certain errors > arising while > > verifying the signature. It seems that for mid dialog requests this > > behaviour could be harmful. What does the UAC for the mid dialog > > request do > > if it receives 436, 437 or 438? If the mid-dialog request was > > solely for the > > purpose of connected identity, it can give up and allow the > call to > > continue > > as is. But if the request was for some other purpose (e.g., > > renegotiating > > the session because of hold, say, or session timer refresh), the > > UAC really > > wants it to work. For the normal case where the Authentication > > Service is at > > a proxy, not at the UAC, the UAC cannot force the Authentication > > Service to > > refrain from putting this unverifiable signature in the mid-dialog > > request, > > so any attempts to repeat the request would most likely be doomed > > to getting > > the same response. > > > > It seems there are three things we could do, none very attractive: > > 1. Get connected-identity to modify the procedures of RFC 4474 for a > > verifier by softening the requirements for sending 436, 437 > and 438 in > > response to mid-dialog requests. But then a mid-dialog > request from > > a rogue > > source would be accepted. > > 2. Say that the Authentication Service should omit the signing of > > mid-dialog > > requests if a previous attempt has resulted in 436, 437 or > 438. But > > this > > implies statefulness at the AS. > > 3. Accept the fact the mid-dialog requests can fail in this way and > > therefore things like session refresh and session renegotiation > > cannot be > > done, probably resulting in call failure. Sounds bad, but it is no > > different > > from an initial INVITE request, where there is nothing the UAC can > > do if the > > AS inserts an Identity header that gets rejected with 436, > 437 or 438. > > > > John > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 22 September 2006 19:26 > >> To: Elwell, John > >> Cc: Cullen Jennings; SIP > >> Subject: Re: Rejecting connected identity (was RE: > >> draft-ietf-sip-connected-id entity-01 comments) > >> > >> John, > >> > >> I want to hear what others, especially Jon and Cullen, have > >> to say about > >> this. > >> > >> It is of some concern to me that a call might fail because of some > >> problem with the identity mechanism when the same call might have > >> succeeded in the absence of any identity. > >> > >> But possibly the solution to this is policy in the > >> implementation of the > >> verifier. What to do in the case of the conditions that > lead to these > >> errors could be configurable in the verifier: either to > generate the > >> error or simply to remove the identity info from the > message. And the > >> policy could conceivably vary based on attributes of the > >> message, such > >> as whether it is in-dialog or not. > >> > >> Does it require a change to 4474 to permit that kind of policy? > >> > >> It would be annoying if the end user had no control over the > >> insertion > >> and verification of identity, and it resulted in calls > >> failing that the > >> user would like to permit. But I suppose that is itself a policy > >> decision. There are certainly enterprises that want to exert > >> that kind > >> of control over what users are permitted to do. > >> > >> Paul > >> > >> Elwell, John wrote: > >>> Paul, > >>> > >>> I agree with most of your points, and on reflection I think > >> I agree that the > >>> solution has to be with the verifier. > >>> > >>> I think RFC 4474 is not a problem as far as sending a 428 > >> 'Use Identity > >>> Header' response is concerned, because that is left to > >> policy, so we could > >>> say in connected-identity that policy should be to not send 428. > >>> > >>> However, 436, 437 and 438 responses are all a problem, > >> because RFC 4474 says > >>> that they MUST be sent under respective conditions. > >> Interestingly, though, > >>> there are other failure scenarios that can arise from the > >> procedures of > >>> section 6 of RFC 4474 for which no normative statement is > >> given on how to > >>> respond, e.g. invalid Date header field, signer not > >> authoritative for the > >>> domain. > >>> > >>> So one way to solve the present problem would be for the > >> connected-identity > >>> draft to modify verifier behaviour in RFC 4474 in the case > >> of mid-dialog > >>> requests. I guess this would mean that it would update RFC > >> 4474 as well as > >>> updating RFC 3261. But I don't like this, because it seems > >> to remove some of > >>> the security properties of RFC 4474. > >>> > >>> Another way would be to accept that 436, 437 and 438 > >> responses will be sent, > >>> and failure to verify a signature will therefore result in > >> inability to > >>> process the UPDATE or re-INVITE request, and hence if the > UPDATE or > >>> re-INVITE request was for some other purpose such as > >> session timer refresh > >>> or modifying the session, that action will fail. Then the > >> call will fail (in > >>> the case of inability to refresh the session timer) or the session > >>> modification will fail. I guess this is somewhat analogous > >> to caller ID > >>> verification failure in an INVITE request - it is > >> impossible to establish a > >>> call if verification fails. Moreover, the UAC has no > >> ability to rectify the > >>> situation, since it is at the mercy of a proxy-based > >> Authentication Service > >>> that puts a rogue Identity header field in every request. > >> In the connected > >>> identity case, the only difference is that the call is > >> already established > >>> but is likely to fail if verification fails. > >>> > >>> Of course, if the mid-dialog request is indeed from the > >> wrong source, then > >>> sending a 436, 437 or 438 response is indeed the correct > >> thing to do, and > >>> overriding the verification procedures of RFC 4474 would > >> indeed be the wrong > >>> thing to do. So perhaps we just have to accept that these > >> response codes can > >>> be received and will lead to failure. > >>> > >>> So, my preferred way forward is simply to recommend not > >> sending a 428 and > >>> accept the consequences of other responses that the > >> verifier might send. > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 22 September 2006 15:13 > >>>> To: Elwell, John > >>>> Cc: Cullen Jennings; SIP > >>>> Subject: Re: [Sip] RE: > >> draft-ietf-sip-connected-identity-01 comments > >>>> > >>>> > >>>> > >>>> Elwell, John wrote: > >>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>> When an Update is sent. Are there any conditions under which > >>>>>> it might > >>>>>> be rejected. Bad identity for example. I think that > >> might need a > >>>>>> little discussion and also what the UA does when it sends > >>>> an update > >>>>>> with a no identity and it gets rejected. > >>>>> [JRE] A very good point. We don't want to get to a > >>>> situation where it is > >>>>> impossible to perform a mid-dialog request (e.g., for > >>>> purposes such as > >>>>> session timer refresh or session re-negotiation) just > >>>> because connected > >>>>> identity fails. > >>>>> My proposed fix is as follows: > >>>>> 1. Say that a UAS SHOULD NOT reject a mid-dialog request > >>>> with 428 'Use > >>>>> Identity Header'. > >>>> I'm not sure about this. At the least I think this one needs > >>>> some clear > >>>> explanation of the SHOULD NOT - about the conditions when > >> it can be > >>>> violated. > >>>> > >>>> I see this as somewhat analogous to doing a digest > challenge on an > >>>> in-dialog request. In some cases it is the right thing to do. > >>>> > >>>> A UA that imposes such a requirement will be limited in what > >>>> it can do, > >>>> but that may still be right in some cases. > >>>> > >>>>> 2. Say that an Authentication Service MUST NOT add an > >>>> Identity header field > >>>>> to a mid-dialog request if a previous request on that > >>>> dialog has resulted in > >>>>> 436 'Bad Identity-Info', 437 'Unsupported Certificate' or > >>>> 438 'Invalid > >>>>> Identity Header'. > >>>> This requirement would force the authentication service to > >> be dialog > >>>> stateful, which is not ideal. Better to push the state > >> back into the > >>>> sender of the request. This may require a way for the UAC > >> to tell the > >>>> authentication service not to act. > >>>> > >>>>> 3. Say that a UAC MUST repeat a mid-dialog request that > >>>> results in one of > >>>>> these responses if the mid-dialog request was not solely > >>>> for the purpose of > >>>>> connected identity. If solely for the purpose of connected > >>>> identity there is > >>>>> no point in repeating it, so I will say "SHOULD NOT take > >> any further > >>>>> action". > >>>> This seems wrong to me. > >>>> > >>>> I think that the remedy to these is in the verifier. The > >>>> purpose of the > >>>> verifier is ultimately to drive an authorization decision. If > >>>> authorization would succeed in the absence of the > >> identity, then the > >>>> request should be permitted to continue as if the identity > >>>> was not present. > >>>> > >>>> Unfortunately this would seem to require a revision to 4474 > >>>> even though > >>>> the paint is hardly dry on it. > >>>> > >>>> If this is done, then there is no need of a mechanism to > cause the > >>>> authentication service *not* to authenticate. If this is > >> *not* done, > >>>> then that need remains, which will still require a > change to 4474. > >>>> > >>>> 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 Sun Oct 29 06:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8kb-0000G1-AN; Sun, 29 Oct 2006 06:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8kL-0000Cs-H3 for sip@ietf.org; Sun, 29 Oct 2006 06:22:33 -0500 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 1Ge8kG-0005VU-Fw for sip@ietf.org; Sun, 29 Oct 2006 06:22:33 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7W0048BA9M4M@siemenscomms.co.uk> for sip@ietf.org; Sun, 29 Oct 2006 11:22:35 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZ4WJ>; Sun, 29 Oct 2006 11:22:23 +0000 Content-return: allowed Date: Sun, 29 Oct 2006 11:22:21 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: TLS meaning To: David R Oran , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A38D735@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: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Joel M. Halpern" , IETF SIP List , Francois Audet , 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 David , > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: 28 October 2006 13:43 > To: Paul Kyzivat > Cc: Joel M. Halpern; IETF SIP List; Francois Audet; Dean Willis > Subject: Re: [Sip] RE: TLS meaning > > Sorry to jump into the middle of the thread, but given the long > chain, I had to pick somewhere to insert my personal opinion. I'll > note that I'm one of the guilty parties in raising the whole > question > about the utility of sips, so I guess I ought to support some way > forward here. There was a suggestion earlier in the thread I really > liked, which I think was: > > a) get rid of sips as a url scheme. > b) write a BCP which says if you get TLS in, send TLS out. > > In what way does this not give us EXACTLY the capability we > have with > SIPS, without all the complexity of a separate url scheme and the > semantic mismatch problems people (including me) keep hammering on > when we compare sips to https. [JRE] UAs that always use TLS for their outbound requests would then not be able to send a request to a destination not reachable via TLS hops. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 29 06:26:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8mT-0001L9-Uf; Sun, 29 Oct 2006 06:24:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8mS-0001Kq-DP for sip@ietf.org; Sun, 29 Oct 2006 06:24:44 -0500 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 1Ge8mR-0005uP-34 for sip@ietf.org; Sun, 29 Oct 2006 06:24:44 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7W0071GADHWQ@siemenscomms.co.uk> for sip@ietf.org; Sun, 29 Oct 2006 11:24:53 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZ4W3>; Sun, 29 Oct 2006 11:24:42 +0000 Content-return: allowed Date: Sun, 29 Oct 2006 11:24:40 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: TLS meaning To: Francois Audet , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F26670A38D736@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: 4d87d2aa806f79fed918a62e834505ca 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 Francois, Taking into account also a ton of further messages on the subject since you posted this, my opinion is as follows. - I see some use in being able to determine that a request is hop-by-hop secured. - The last hop must not be excluded from this, although we might need to allow the desired level of security to be achieved by some different means in cases where sip-outbound can't be used (mobile UAs). - For all hops, we must somehow specify what forms of security is acceptable, e.g., by enumerating TLS/DTLS cipher suites. - I would also find a best effort signalling security solution beneficial. At present there is no mechanism to achieve this and find out whether you got it or not, except by trying SIPS and if failing trying SIP - not very efficient. So whilst I go along with the principle of trying to fix SIPS in the sense of having a well-specified hop-by-hop security mechanism, it does appear that it will require quite a lot of work to fix it. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 27 October 2006 17:12 > To: IETF SIP List > Subject: RE: [Sip] RE: TLS meaning > > In case people having noticed, it is looking like we are having a > mailing list > hum on the following 2 questions: > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > > 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) > > > Note: Voting Yes on 2 does not necessarily imply you are > voting No on 1, > but it will > only make sense if sips is not deprecated. > > I'm keeping track of the vote. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 29 06:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8ni-0003nV-EU; Sun, 29 Oct 2006 06:26:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge8mt-0002Kn-Fb for sip@ietf.org; Sun, 29 Oct 2006 06:25:11 -0500 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 1Ge8mr-00063f-45 for sip@ietf.org; Sun, 29 Oct 2006 06:25:11 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7W0071UAE7WQ@siemenscomms.co.uk> for sip@ietf.org; Sun, 29 Oct 2006 11:25:19 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZ4WP>; Sun, 29 Oct 2006 11:25:08 +0000 Content-return: allowed Date: Sun, 29 Oct 2006 11:25:07 +0000 From: "Elwell, John" Subject: RE: [Sip] RE: TLS meaning To: Francois Audet , Michael Thomas Message-id: <50B1CBA96870A34799A506B2313F26670A38D737@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: 02ec665d00de228c50c93ed6b5e4fc1a 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: Francois Audet [mailto:audet@nortel.com] > Sent: 28 October 2006 00:26 > To: Michael Thomas > Cc: IETF SIP List > Subject: RE: [Sip] RE: TLS meaning > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, October 27, 2006 4:20 PM > > To: Audet, Francois (SC100:3055) > > Cc: IETF SIP List > > Subject: Re: [Sip] RE: TLS meaning > > > > Francois Audet wrote: > > > > >Please calm down. > > > > > >Here is one simple scenario. > > > > > >I deploy an Enteprise SIP network. I install 10 SIP proxies > > accross the > > >Corporate Network. All the proxies are certified to properly > > implement > > >SIPS. All the phones are also certified to implement SIPS > > properly. I > > >know, because I am responsible for the network. > > > > > >An end user can call another end-user within that network with the > > >certitude that if sips is used, it will be secured end-to-end. > > > > > > > How about an example when it's not all within the same > > administrative entity. How abouts some examples that > > resemble, oh say, the mail system. > > These have always been where my concerns are. Within my own > > domain, I don't need SIPS; I can do that by executive fiat. > > In that case, if you don't have trust with them, then don't use > sips. As simple as that. > > Yes you need sips in your own domain, because some devices > support TLS, > others don't. Some users want to be addressed securily, others don't. [JRE] In the sort of domains you have in mind, it is likely to be UAs that don't support SIPS, and hence the importance of changing the last hop exception rule. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 29 10:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeCid-0005zV-Gx; Sun, 29 Oct 2006 10:37:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeCht-0005bD-2K for sip@ietf.org; Sun, 29 Oct 2006 10:36:17 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeChr-0008IC-H8 for sip@ietf.org; Sun, 29 Oct 2006 10:36:17 -0500 Received: by nf-out-0910.google.com with SMTP id n15so1987058nfc for ; Sun, 29 Oct 2006 07:36:14 -0800 (PST) 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=hqHCK2OZYXSW/v1qsY3DFP1+dNiHnRHOVr4rdkKr/O4uYOm0zGjH0NPsx4jXB3QqRwRYL/4zKSPzcN8qTCZXSbTyEXlHNdmQ3MIoyjrdH95haoV5jf3yiJ8JtxTlMzDhwwmN+isV8XUBxIFO3Wyu1ix7W4f0rKyS7RT5O6LS7qg= Received: by 10.78.203.15 with SMTP id a15mr3217856hug; Sun, 29 Oct 2006 07:36:14 -0800 (PST) Received: by 10.78.200.9 with HTTP; Sun, 29 Oct 2006 07:36:13 -0800 (PST) Message-ID: <953beacc0610290736l34378384h21422d7d13289524@mail.gmail.com> Date: Sun, 29 Oct 2006 07:36:13 -0800 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <45426B08.4040901@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> <45426B08.4040901@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Sorry, I was a little sloppy in my description. Inline. On 10/27/06, Jonathan Rosenberg wrote: > inline. > > Rohan Mahy wrote: > > > Hi Eric, > > > > > > On 10/26/06, Eric Rescorla wrote: > > > >> I always have trouble learning from examples, so I hope you'll > >> forgive me if I've misunderstood. > > > > > > Of course. > > > >> It seems to me that there are three key points to this proposal: > >> > >> 1. The "limited-use" GRUU is tied to the long-term GRUU rather than > >> to an AOR. > > > > yes. one advantage IMO is that the lifetime of the limited-use GRUU > > is unrelated to the stability of the underlying connection. I can > > fetch a limited use GRUU, go into a tunnel, come out with a different > > IP address, and reregister my instance without having to refresh any > > of my limited-use GRUUs. > > I'm confused. In the current -11 mechanism, the same thing is true; if > you go into a tunnel and you get a new IP address when you come out, you > register with a new IP address and the same instance ID. All existing > gruu continue to work. There are no extra registrations. You said below that the lifetime of my private GRUU is the lifetime of my registration. I am assuming here that the old registration gets replaced when I come out of the tunnel and reregister. Does the old private GRUU I handed out cease to work? If so my UA needs to inform any other UAs that might be using my private GRUU. With the proposal I described the private GRUU has a completely independent lifetime. It is still valid when you come out of the tunnel. If a UA gave this private GRUU to another UA, it doesn't need to replace a previously given GRUU. Also, the explicit lifetime provides another advantage. If I have a device which is registered continuously for weeks at a time, any private GRUU I received as a side effect of refreshing my subscripion is still valid. If I start to get SPIM to one of these private GRUU, the only mechanism I have to squelch the SPIM at my authoritative proxy is to reregister using a new Call-ID. If I gave other private GRUU out that are still useful to me, I need to replace them. If UAs offer a feature that blocks calls or IMs to a specific GRUU, it seems like they need to remember all the currently active private GRUU, which could be a substantial number of URIs. > However your mechanism has the major disadvantage of requiring an extra > REGISTER to allocate a new temporary gruu prior to an anonymous call. > That extra registration is a big deal for many systems. COnsider the > craziness IMS goes through when a register happens. You only need a new register if you don't have a private GRUU cached. This might mean I need to have my phone off for a whole week to not have a GRUU. For emergency calls, I suspect its OK to use your public GRUU. Also none of the traditional IMS machinations are necessary for this kind of REGISTER. Its effectively a third-party registration. > >> 2. The client explicitly controls limited-use GRUUs rather than > >> having them issued by the server as an automatic side effect > > > > yes. if I want a 5 minute validity GRUU or a week long validity GRUU > > I can get one and refresh (or not) independently. > > WIth whats in -11 the idea is that the lifetime is the length of your > registration, and that normally you are not wanting to kill the validity > of the temporary gruu - thats not a privacy issue, its a spam issue. If > you do want to kill it, you can use the consent framework for example to > do that. But thats a secondary need. I don't consider limited-lifetimes a secondary need. Limited lifetime GRUU deals with reaching a UA instance directly, whereas the consent framework is most likely doing screening for my public AOR. > > I can also get a GRUU that is limited use but still tied to my AOR. > > Possibly useful for allowing that pesky salesperson to bypass my call > > screening for a day or two about something important. > > > > As for load, the UA only generates load on the server when it needs > > something new. If the UA doesn't need any private GRUU, the server > > doesn't need to generate one. If the UA wants a unique GRUU per-call, > > the registrar does not need to do a full outbound-style registration > > (making and saving flow tokens, etc.) > > In -11 there is no extra messaging load on the server beyond regular > registration handling, and it gives the client a near infinite suppy of > unlinkable addresses, so that a user can use a different one in each > call without any additional signaling. The point here is that I want to skip the "regular registration handling" part, which has become increasingly heavy with outbound and with IMS. I can implement the limited-use GRUU registration statelessly without requiring a write to the location service. > >> 3. The client proposes the limited-use GRUU, not the server. > > > > no, the server still forms the actual lmited-use GRUU. > > THen I'm confused like ekr. I thought your proposal had the contact of > the second registration containing the temporary gruu. In my example, the Contact of the second registration contains the *public GRUU*. The ;gruu parameter in each Contact header field value in the 2xx response to the register contains the *limited-use* GRUU. 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 Sun Oct 29 11:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeD43-000784-33; Sun, 29 Oct 2006 10:59:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeCze-0001Ce-8R for sip@ietf.org; Sun, 29 Oct 2006 10:54:38 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeCqk-0001jK-Pk for sip@ietf.org; Sun, 29 Oct 2006 10:45:28 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id CA6FB1E8C28; Sun, 29 Oct 2006 07:45:25 -0800 (PST) To: "Rohan Mahy" Subject: Re: [Sip] Updated GRUU spec - big changes References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> <45426B08.4040901@cisco.com> <953beacc0610290736l34378384h21422d7d13289524@mail.gmail.com> From: Eric Rescorla Date: Sun, 29 Oct 2006 07:45:25 -0800 In-Reply-To: <953beacc0610290736l34378384h21422d7d13289524@mail.gmail.com> (Rohan Mahy's message of "Sun, 29 Oct 2006 07:36:13 -0800") Message-ID: <86fyd7gm7e.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: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF SIP List , "Drage, Keith \(Keith\)" 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 "Rohan Mahy" writes: > On 10/27/06, Jonathan Rosenberg wrote: > Also, the explicit lifetime provides another advantage. If I have a > device which is registered continuously for weeks at a time, any > private GRUU I received as a side effect of refreshing my subscripion > is still valid. If I start to get SPIM to one of these private GRUU, > the only mechanism I have to squelch the SPIM at my authoritative > proxy is to reregister using a new Call-ID. If I gave other private > GRUU out that are still useful to me, I need to replace them. This feature is more easily implemented with client-issued tokens on each GRUU. > If UAs offer a feature that blocks calls or IMs to a specific GRUU, it > seems like they need to remember all the currently active private > GRUU, which could be a substantial number of URIs. It's really not that much memory, and you can use a variety of cryptographic techniques to limit it. >> >> 3. The client proposes the limited-use GRUU, not the server. >> > >> > no, the server still forms the actual lmited-use GRUU. >> >> THen I'm confused like ekr. I thought your proposal had the contact of >> the second registration containing the temporary gruu. > > In my example, the Contact of the second registration contains the > *public GRUU*. The ;gruu parameter in each Contact header field value > in the 2xx response to the register contains the *limited-use* GRUU. OK. Well that partially fixes the problem, but not completely: the feature you propose where the server is required to give you back every GRUU its issued requires per-GRUU state on the server, which is an explit requirements violation. Let's uplevel a bit: I'm not fixated on JDR's current mechanism, and I'd be happy to consider an alternative that provided superior properties. That said, I'm not finding documentation by example and e-mail thread very easy to manage. How about you write a draft on your approach and its advantages and then JDR, I, and others can read and comment? -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 Sun Oct 29 11:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeD6J-0000JK-7O; Sun, 29 Oct 2006 11:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeCzs-0001Mt-EG for sip@ietf.org; Sun, 29 Oct 2006 10:54:52 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeCku-0000po-5V for sip@ietf.org; Sun, 29 Oct 2006 10:39:27 -0500 Received: by nf-out-0910.google.com with SMTP id n15so1987873nfc for ; Sun, 29 Oct 2006 07:39:23 -0800 (PST) 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=Ht2yC9E7ekh4HdY2ArBfVDeCFGMo6GI5VEWg0nDuJI/LsmO/dRzMcEKT0u1OOXy0rwKxBnpa5JTWUgTXnRK0gSpYNhxRpG4G1iv+2ouJJt1jMNuVdOWlLUGwVJnfjN8SlO/3ULT53DkzesgMSpdjJV6OLdHMv8b/isV+8IMKH3o= Received: by 10.78.204.1 with SMTP id b1mr3199981hug; Sun, 29 Oct 2006 07:39:22 -0800 (PST) Received: by 10.78.200.9 with HTTP; Sun, 29 Oct 2006 07:39:22 -0800 (PST) Message-ID: <953beacc0610290739r5f585c77x20c2d14af493f0a9@mail.gmail.com> Date: Sun, 29 Oct 2006 07:39:22 -0800 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] Updated GRUU spec - big changes In-Reply-To: <86ejstld3p.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D1A7985295922448D5550C94DE2918069AE00@DEEXC1U01.de.lucent.com> <953beacc0610261143r661a4424w12e4d41b8f631368@mail.gmail.com> <86fydaoh2v.fsf@raman.networkresonance.com> <953beacc0610271150u3f2e6c90m5135d1510ac0d9c7@mail.gmail.com> <86ejstld3p.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 10/27/06, Eric Rescorla wrote: > >> 2. The client explicitly controls limited-use GRUUs rather than > >> having them issued by the server as an automatic side effect > > yes. if I want a 5 minute validity GRUU or a week long validity GRUU > > I can get one and refresh (or not) independently. > > > > I can also get a GRUU that is limited use but still tied to my AOR. > > Possibly useful for allowing that pesky salesperson to bypass my call > > screening for a day or two about something important. > > > > As for load, the UA only generates load on the server when it needs > > something new. If the UA doesn't need any private GRUU, the server > > doesn't need to generate one. If the UA wants a unique GRUU per-call, > > the registrar does not need to do a full outbound-style registration > > (making and saving flow tokens, etc.) > > I'm not an expert on SIP stacks, so maybe I'm missing something > here, but doesn't JDR's new draft have a lightweight way to > fetch a new anonymous GRUU? Not that I am aware of. The registrations in GRUU-11 still require a write to the location service. 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 Sun Oct 29 11:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeDFU-0003ck-DQ; Sun, 29 Oct 2006 11:11:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeD5J-00085u-DY for sip@ietf.org; Sun, 29 Oct 2006 11:00:29 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeD5E-0004dO-Uj for sip@ietf.org; Sun, 29 Oct 2006 11:00:29 -0500 Received: by nf-out-0910.google.com with SMTP id n15so1993281nfc for ; Sun, 29 Oct 2006 08:00:22 -0800 (PST) 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=GpuBIN80tPHsJaidXA3t2OcCYFfcNil28Vx52ArWNY+fpozrgfxZCi3NxhyTY8wdi+pDS/o9dEM8aZSWszj6GBXTqP1l6HGOUWfxWrBIm4Cb9HIWZlUmGdPSfmMXws3l3WlklustwAUOeG/fVNVNfoU8K7TmlJCkPS3Rdm+KmWk= Received: by 10.78.128.15 with SMTP id a15mr3247973hud; Sun, 29 Oct 2006 08:00:21 -0800 (PST) Received: by 10.78.200.9 with HTTP; Sun, 29 Oct 2006 08:00:21 -0800 (PST) Message-ID: <953beacc0610290800x47f2c7dbv342e6de9288b0421@mail.gmail.com> Date: Sun, 29 Oct 2006 08:00:21 -0800 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <454134E1.8040900@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <20061025002453.B63121CC5D@delta.rtfm.com> <953beacc0610251257p6a4d1ecbvca89f466473b8380@mail.gmail.com> <86fydcqfdx.fsf@raman.networkresonance.com> <953beacc0610251707j5777516bsa6551ca494d5f91b@mail.gmail.com> <86y7r3q49n.fsf@raman.networkresonance.com> <953beacc0610261137q4605412aja44bfa93f718ecc@mail.gmail.com> <454134E1.8040900@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Jonathan, I don't understand what you mean by "much later". The grid parameter appears in draft-ietf-sip-gruu-00, dated January 2004. I do not consider it a "nice-to-have". I think it is essential to make several features work, including local conferencing. It merely restores the ability of the UA to manufacture a large number of distinct Contact URIs. I am somewhat mystified that the very old problem of passing qualifiers through from an AOR to a UA has suddenly come to such prominence that it was able to disrupt stable working functionality in a high-priority WG draft. What suddenly changed in the priorities of... oh, look a shiny penny! thanks, -rohan On 10/26/06, Jonathan Rosenberg wrote: > To summarize, I think you are saying: > > 1. I dont like the mechanism, and > 2. whatever the mechanism is, has to be a normative ref from GRUU as > MUST implement, or part of GRUU > > I responded to your concern (1) in another note. > > I'd like to understand your motivation on (2). The grid feature of GRUU > was considered nice-to-have (it came only much later in the GRUU > evolution), and all of the things people wanted to do with it are > equally applicable to the AOR (as ekr pointed out), and so have very > little to do with the problem GRUU was intending to solve - addressing a > UA directly. Why do you see a solution for these two as being coupled? > > -Jonathan R. > > Rohan Mahy wrote: > > > Ekr, > > > > As I said in an earlier mail (perhaps not as clearly as necessary), if > > you want to propose a general grid-like mechanism that satisfies the > > requirements of grid and also extends this "pass-along" property of a > > parameter to AORs *without resorting to UAs handling Route headers*, I > > am generally supportive. I would want to include this mechanism either > > in the GRUU draft itself or in a small document that GRUU normatively > > references and that any GRUU-supporting device MUST implement. > > > > thanks, > > -rohan > > > > On 10/25/06, Eric Rescorla wrote: > > > >> "Rohan Mahy" writes: > >> > On 10/25/06, Eric Rescorla wrote: > >> >> Right, that's just one way of implementing. My point in responding > >> to your > >> >> message was that a parameter that is GRUU-only to do a task that is > >> >> applicable outside of GRUU is a Bad Thing. > >> > > >> > Postponing this *agreed-upon* functionality for GRUU to depend on a > >> > brand-new untested mechanism is a MUCH WORSE Thing. > >> > >> I don't agree, but I think we're talking past each other here. > >> > >> Prior to this change GRUU defined a mechanism whereby the UAC could > >> add a disambiguator to a GRUU. My point is that whatever mechanism > >> we choose should have applicability outside of GRUU. > >> Are you objecting to this? If so, why? > >> > >> I appreciate that you think the particular proposed mechanism to attack > >> this problem is bad, but that's not what I'm arguing for here... > >> > >> -Ekr > > > > > > -- > 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 Sun Oct 29 13:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeFmm-0002zd-5c; Sun, 29 Oct 2006 13:53:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeFlF-0000v8-GH for sip@ietf.org; Sun, 29 Oct 2006 13:51:57 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeFdp-0000SQ-FD for sip@ietf.org; Sun, 29 Oct 2006 13:44:18 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 129801CC22 for ; Sun, 29 Oct 2006 10:44:10 -0800 (PST) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 29 Oct 2006 10:44:09 -0800 From: EKR Message-Id: <20061029184410.129801CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] Comments on draft-rosenberg-sip-ua-loose-route-00.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 $Id: draft-rosenberg-sip-ua-loose-route-00-rev.txt,v 1.1 2006/10/29 18:46:14 ekr Exp $ This generally seems like a sound idea and the draft is pretty well written. The extensive backward compatibility considerations make me a bit nervous, but not being a real SIP routing expert, I can't say if there will be problems in practice. S 2.1: sip:john.smith@example.com and sip:jsmith@example.com. Rather than registering against each of these AORs individually, the user would register against just one of them, and the home proxy would automatically accept incoming calls for any of the aliases, treating them identically and ultimately forwarding them towards the UA. This sentence is hard to read. I think it's describing what happens now, but the use of "Rather...would" suggests that it's what you want to do after this draft, so.. S 2.3: Limited use addresses are used in battling voice spam [6]. Well, we'd like them to be. Maybe s/are/can be/ particular correspondent, and remember that URI locally. When an incoming call arrives, the UAS would examine the parameter in the URI and determine whether or not the call should be accepted. This is one way to do it, but the alternative is a cryptographic cookie and keeping a blacklist. S 3: There is a common theme across all of the problems in Section 2, and this theme is the confounding of names, routes, and addresses. A name is a moniker for an entity which refers to it in a way which I'm not sure you want to use "moniker" here. I would think that you have "identifiers" (i.e., names), "routes", and "locators" (i.e., addresses) S 5: 3. When a proxy receiving a request identifies a next hop server that is needed to process the request, that next hop server is a route. A next hop server is not a UA and would never be able to claim its identity. Its URI is pushed into a Route header field and the Request-URI is retained. An important use case for this are proxies that select PSTN gateways for call egress to the PSTN. Such selection would place the SIP URI of the gateway into the topmost Route header field value and retain the Request-URI. I think this could be clearer, but I'm not sure I understand it well enough to rewrite... -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 Sun Oct 29 14:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeFtT-00071D-8h; Sun, 29 Oct 2006 14:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeFnv-0003FW-71 for sip@ietf.org; Sun, 29 Oct 2006 13:54:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeFnr-0003I8-Rz for sip@ietf.org; Sun, 29 Oct 2006 13:54:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2006 10:54:39 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9TIsdRL009820; Sun, 29 Oct 2006 10:54:39 -0800 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 k9TIscAo021381; Sun, 29 Oct 2006 10:54:38 -0800 (PST) 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); Sun, 29 Oct 2006 10:54:38 -0800 Received: from caryfitz-mac.local ([10.21.147.53]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Oct 2006 10:54:38 -0800 Received: by caryfitz-mac.local (Postfix, from userid 501) id 4671D228064; Sun, 29 Oct 2006 10:54:34 -0800 (PST) Date: Sun, 29 Oct 2006 10:54:34 -0800 (PST) From: Cary FitzGerald X-X-Sender: caryfitz@caryfitz-mac.local To: "Elwell, John" Subject: RE: [Sip] RE: TLS meaning In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D736@ntht201e.siemenscomms.co.uk> Message-ID: References: <50B1CBA96870A34799A506B2313F26670A38D736@ntht201e.siemenscomms.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Oct 2006 18:54:38.0347 (UTC) FILETIME=[AF1B5DB0:01C6FB8B] Authentication-Results: sj-dkim-2.cisco.com; header.From=caryfitz@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 On Sun, 29 Oct 2006, Elwell, John wrote: > Francois, > > Taking into account also a ton of further messages on the subject since you > posted this, my opinion is as follows. > > - I see some use in being able to determine that a request is hop-by-hop > secured. > - The last hop must not be excluded from this, although we might need to > allow the desired level of security to be achieved by some different means > in cases where sip-outbound can't be used (mobile UAs). I've always thought that one of the interesting properties of SIP is that in general there is no way to know this is "the last hop." Proxies forward methods to... something. Could be a proxy, could be a UA. If "last hop" means "into a trusted zone," then it logically follows that the signaling should have been secured outside of the trusted zone. By definition the thing (UA or proxy) that handed the message to this "last hop" proxy is outside that zone. > - For all hops, we must somehow specify what forms of security is > acceptable, e.g., by enumerating TLS/DTLS cipher suites. And therefore, I agree with you. > - I would also find a best effort signalling security solution beneficial. > At present there is no mechanism to achieve this and find out whether you > got it or not, except by trying SIPS and if failing trying SIP - not very > efficient. A UA/proxy is free to bid up security and use TLS even if it's not required. As a UA I might do so on its first hop to the service provider. Cary. > > So whilst I go along with the principle of trying to fix SIPS in the sense > of having a well-specified hop-by-hop security mechanism, it does appear > that it will require quite a lot of work to fix it. > > John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 29 14:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeG9D-0002cL-2t; Sun, 29 Oct 2006 14:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeG95-0002c5-U6 for sip@ietf.org; Sun, 29 Oct 2006 14:16:35 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeG94-0000IC-FZ for sip@ietf.org; Sun, 29 Oct 2006 14:16:35 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 3BD681CC22 for ; Sun, 29 Oct 2006 11:16:27 -0800 (PST) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 29 Oct 2006 11:16:27 -0800 From: EKR Message-Id: <20061029191627.3BD681CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Sip] Comments on draft-gurbani-sip-domain-certs-03- X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Id: draft-gurbani-sip-domain-certs-03-rev.txt,v 1.1 2006/10/29 19:14:00 ekr Exp $ The subject of this draft is what identities should appear in the TLS certificates presented by SIP clients and servers. To refresh people's memories, here's some background from my review of the -01 version of this draft: Let's take a step back and examine first principles: The basic assumption behind RFC 2818 (and most other uses of TLS) is that you start with some URI X that you want to dereference. Through some series of (untrusted) manipulations you end up with a connection to some endpoint which presents you a certificate C. You then need to determine whether X matches C. In order for this process to work properly, X needs to either contain C or there needs to be some trusted transformation between C and X. In the Web context, what this means is that if you have a server farm with A.example.com, B.example.com, C.example.com, etc. then they all have certificates containing "www.example.com". This can either be done via key-sharing or can be done by issuing them separate certificates that all contain the same domain name ("www.example.com"). This is basically the practice that people have assumed for RFC 3261. The authors of this draft argue that this is a problem because proxy farms want to use record routes to force routing back through a particular member of the proxy farm: While this is not a concern when choosing any proxy from a server farm, it is a problem when the choice of a proxy needs to be deterministic. One way to combat this is to arrange for the proxy to possess two certificates -- one corresponding to "sips:example.com" and the other corresponding to "sips:downtown.example.com" -- and have it present the right one when contacted. While technically this is feasible through the use of TLS extensions [7], administratively it requires the proxy vendor to acquire two distinct certificates. In this document, we propose the use of one certificate with two identities as a possible way to counter this particular problem. I'm skeptical that this is really going to be an important scenario. If you want to have high availability (and presumably if you run a proxy farm you do) you need to have proxy operations either be stateless or arrange for state clustering, in which case getting something back to the wrong proxy just looks like a cache niss. Moreover, once outbound and draft-ietf-sip-connect-reuse-05 are deployed, I would expect to see quite a bit of stickiness. That said, it does seem relatively easily solved just by saying "if you ever serve multiple names, you need some way to deal with it." S 5. I don't understand why you're separating out RFC 3263 versus non-3263 identities here. If you think you should have a cert with multiple names, let's just have them be undifferentiated. S 9. Is it conceivable that each domain have a distinct certificate that is provided to the hosting service? Certainly, this means that the domain must share the domain's private key with the hosting service. TLS extensions [7] like the extended client hello allow TLS clients to provide to the TLS server the name of the server they are contacting. Thus, the server can present the correct certificate to establish the TLS connection. The appropriate thing here seems to be to follow HTTPS practice. Each domain has its own key pair and cert. The hosting service has the private key. You use name-based virtual hosting if you can trust clients to provide the dns_name. Otherwise you use IP-based. The following rules seem appropriate: 1. Nothing prohibits SIP servers certs from having multiple names. 2. Clients should accept certificates with multiple names. 3. Clients should deterministically check for the presence of one name (the one in whatever they're dereferencing) and ignore others. 4. Servers which wish to act for multiple identities should either (a) have a certificate with multiple names (b) use some form of virtual hosting. 5. Clients should generate the dns_name extension. Have I missed something? -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 Sun Oct 29 14:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGV1-0002zK-Js; Sun, 29 Oct 2006 14:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGUv-0002xm-R4 for sip@ietf.org; Sun, 29 Oct 2006 14:39:09 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeGUu-0005IY-Cl for sip@ietf.org; Sun, 29 Oct 2006 14:39:09 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1FCC31CC22 for ; Sun, 29 Oct 2006 11:39:01 -0800 (PST) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 29 Oct 2006 11:39:01 -0800 From: EKR Message-Id: <20061029193901.1FCC31CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Sip] Comments on draft-ietf-sip-gruu-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 $Id$ This draft seems like a big improvement over -10. That said, I still have some comments. GENERAL The opposition of "public" GRUUs versus "temporary" GRUUs seems a bit weird. Aren't these orthogonal? I suggest names which actually are opposites. E.g., "public" vs. "private" or "opaque" vs. "non-opaque" (nothing like a non to make things opposites). S 3.1.1. call attempts. If the UA had made a call towards a GRUU (perhaps as s/towards/to/? S 3.1.2. I think an example of such a GRUU would be appropriate here. S 4.1: Can you show an example of an appropriate REGISTER request (cribbing from the extended example later is fine). S 4.2. instance, respectively. A UA MUST be prepared for a Contact header field to contain just a "pub-gruu", just a "temp-gruu", neither, or both. The temporary GRUU will be valid for the duration of the registration, while the public GRUU persists across registrations. The UA will receive a new temporary GRUU in each successful REGISTER response, while the public GRUU will typically be the same. However, Is there a reason to not have GRUU delivery by the server be all-or-nothing? I.e., you get a public GRUU and a temporary GRUU or no GRUUS at all? remains registered. If a UA stores any temporary GRUUs for use during its registration, it needs to be certain that the registration does not accidentally lapse due to clock skew between the UA and registrar. Consequently, the UA MUST refresh its registration well in advance of expiration. This doesn't seem like a MUST to me. There are environments where the clocks are well synched and I don't know what "well in advance of" means anyway. S 4.4. registrar. Of course, when a UA wishes to construct an anonymous request as described in RFC 3323 [16], it SHOULD use a temporary s/Of course// S 4.5. 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- s/Its/Their/ S 4.6. resulting URI will be seemingly random. Future work may provide improved mechanisms that would allow an automata to know that a URI is anonymized and thus should not be rendered. Why isn't the rule "if gr has no parameters, it's anonymous" fine here. Also, the singular of automata is automaton. S 5.1. If the contact URI is equivalent (based on URI equivalence in RFC 3261) to the AOR, the registrar MUST reject the request with a 403, since this would cause a routing loop. If the contact URI is a GRUU for the AOR in the To header field of the REGISTER request, the registrar MUST reject the request with a 403, for the same reason. If the contact is not a SIP URI, the REGISTER request MUST be rejected with a 403. Is this normal REGISTER behavior non-specific to GRUU? S 5.1/5.2. I see how the "generate a new temp GRUU" in 5.1 and then "send the most recent temp GRUU" in 5.2 work together, but I think it would be less confusing (and less error prone) to have "generate a new temp GRUU and send it" in one place. S 5.3. If, as a consequence of the expiration of the contact, a particular GRUU no longer has any registered contacts bound to it, and the GRUU is a temporary GRUU, the GRUU MUST be destroyed. This means that all of the accumulated temporary GRUUs get destroyed once the last contact for a given instance ID expires. A consequence of this destruction is that requests addressed to the GRUU will be rejected by the domain with a 404 from this point forward. It's not clear what destroyed means if you have a cryptographically generated stateless GRUU. The "as if" rule seems appropriate here. S 5.4. You should explain how it is you get two contacts for one GRUU. S 10.2. It's worth noting that you can use cryptographic techniques that block this kind of substitution attack. S A.2. I note that you could use a nonce instead of a timestamp here.. -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 Sun Oct 29 14:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGhv-0007TV-25; Sun, 29 Oct 2006 14:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeGhr-0007Q0-BN for sip@ietf.org; Sun, 29 Oct 2006 14:52:31 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeGhq-0000Aj-1l for sip@ietf.org; Sun, 29 Oct 2006 14:52:31 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id A26F71CC22 for ; Sun, 29 Oct 2006 11:52:22 -0800 (PST) To: sip@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 29 Oct 2006 11:52:22 -0800 From: EKR Message-Id: <20061029195222.A26F71CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Sip] Comments on draft-ietf-sip-outbound-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org $Id: draft-ietf-sip-outbound-05-rev.txt,v 1.1 2006/10/29 19:54:58 ekr Exp $ Some mostly editorial comments. S 1. Configuration Protocol). These systems typically do not have a useful name in the Domain Name System (DNS), and they definitely do not have a long-term, stable DNS name that is appropriate for use in the subjectAltName of a certificate, as required by [RFC3261]. s/definitely/with high probability/ You can have dynamically assinge dstatic names. request, the proxy can later use this same network "flow", whether s/, /--/ this is a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept of another transport protocol to forward any s/protocol to/protocol--to/ requests that need to go to this UA. For a UA to receive incoming S 3.1. both reach the same UA. The registrar can use the reg-id label to recognize that a UA is registering after a reboot or a network s/registering/re-registering/? S 3.4. I think a ladder diagram would help here. S 4.1. A UA SHOULD use a UUID URN [RFC4122]. add to the end "as its instance ID" S 4.2. UAs obtain at configuration time one or more SIP URIs representing "At configuration time UAs obtain..." S 6. comparison purposes. A Contact header field value with an instance-id but no reg-id is valid, but one with a reg-id but no instance-id is not. If the registrar processes a Contact header When would instance-id but no reg-id happen? In addition, unless the registrar has positive knowledge that the topmost Path header URI is reachable from the authoritative proxy, it must store the flow information for the previous hop. The registrar s/must/MUST/ however implementations need to be preared to receive STUN messages which cross a stream buffer boundary, and SIP and STUN messages which share the same stream buffer. I don't understand what this means. If you mean that any time you call read(1) you might get SIP and STUN messages intermixed, isn't that a basic property of TCP? -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 Sun Oct 29 16:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeI1j-00076l-PP; Sun, 29 Oct 2006 16:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeI1h-0006wa-Ss for sip@ietf.org; Sun, 29 Oct 2006 16:17:05 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeI1e-00063n-E7 for sip@ietf.org; Sun, 29 Oct 2006 16:17:05 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 909996C017; Sun, 29 Oct 2006 16:16:51 -0500 (EST) Subject: Re: [Sip] Updated GRUU spec - big changes From: Scott Lawrence To: Jonathan Rosenberg In-Reply-To: <453DA2F3.1070009@cisco.com> References: <453DA2F3.1070009@cisco.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 29 Oct 2006 16:16:57 -0500 Message-Id: <1162156617.24425.59.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Tue, 2006-10-24 at 01:21 -0400, Jonathan Rosenberg wrote: > * added "anonymous gruu", known as temporary gruu. A temporary GRUU is > assigned when you first register a contact, and an additional one is > created on each refresh. All of the ones accumulated over the > lifetime of the registration remain valid. Each of them obfuscate > the AOR and instance ID. Added a description of a stateless > algorithm for computing these. Lengthy discussion on the privacy > implications of using them. Several comments on this: - I agree with EKR that calling the anonymous gruu a "temporary gruu" is not clear. The essential characteristic of it is not that it is temporary - it is no more temporary than any other contact value, and possibly no more temporary than the public gruu value. - I don't understand why it should be true that the 'temporary' gruu should be both reissued at every refresh and be valid for the same duration as the accompanying 'public' gruu. Despite the inclusion of a non-normative way to do this in the document, I don't think that changing the normal rules for the expiration of registrations in that way is needed, and it puts additional burden on registrars to implement it. - I don't see the specific value in having the registrar always return two gruu values. If both sorts are needed, then I think it would be better to have a request parameter that specifies which is wanted. That would allow the registrar to indicate that it can or cannot provide a gruu with the requested properties. The specification should just describe the qualities of each sort of gruu, including how to tell one from the other. - The proposed construction of the 'public' gruu has the property that it is also equivalent by 3261 URI rules to the same AOR without the 'gr' parameter. Doesn't this break the basic characteristic of the gruu - that it addresses a specific instance? Suppose that two UAs both register sip:alice@example.com. The first supports gruu and provides an instance identifier, so it is issued a public gruu; the second does not support gruu, so the binding is just from the AOR to the contact it provides. The first UA communicates its GRUU to Bob somehow, and then unregisters itself, destroying the gruu. Bob then sends a request to the gruu - by 3261 rules, it should be routed to the second UA because 'sip:alice@example.com;gr=kjh29x97us97d' is equivalent to 'sip:alice@example.com'. I think that this, and the associated property that the draft calls semi-permanence is actually undesirable - it blurs the distinction between the specificity of the gruu value and the AOR. I think that it would be better to use the reverse construction in which the AOR is provided as a specific parameter to a locally unique value selected by the registrar: sip:gruu~kjh29x97us97d@example.com;gr-aor=alice@example.com > * changed name of 'gruu' URI parameter to 'gr'. This parameter can now > take a value, folding in the functionality of 'opaque'. Removed the > opaque parameter. > * removed SIPS related processing rules Those are improvements. > * added a check in an originating proxy to make sure that the GRUU in > the INVITE matches the identity of the requestor. THis prevents an > attack whereby a malicious user could cause mid-dialog requests sent > by their peer to be targeted to a DoS target. I assume that you are referring to this paragraph: If an originating authoritative proxy receives a dialog-forming request, and the Contact header field contains a GRUU in the domain of the proxy, and that GRUU is associated with the AOR matching the authenticated identity of the requestor (assuming such authentication has been performed), and the request contains Record-Route header fields, the authoritative proxy MUST record route. If the request contained a GRUU in the domain of the proxy, but this GRUU had an AOR which did not match the authenticated identity of the requestor, it is RECOMMENDED that the proxy reject the request with a 403. I'm pretty sure I don't understand that. There seem to be two requirements there that both apply only to dialog forming requests that have a GRUU: - one that requires that the proxy add a record-route for itself to any such request that it does pass on. Why? Any request directed toward that GRUU value will be sent to the proxies domain anyway eventually. If this is an attempt to prevent an attacker from diverting in-dialog requests by record-routing, I don't see how this helps: even if the proxy adds itself in a record-route, it will still obey the attackers record-route when it arrives, even if the request uri is a local gruu; or were you suggesting that it should replace the record-routes in the message? - the second requirement is vague in that it says "If the request contained a GRUU in the domain of the proxy" - contained where? in the Contact header? In the request URI? Is the intent of this one simply that the authoritative proxy should reject a dialog forming request that has a GRUU for a Contact but cannot authenticate itself as coming from the identity to which that GRUU is mapped? Is this a sort of back-door Identity mechanism, or is there something else intended? > * softened requirements around record-routing for home proxies. The > final algorithm differs for the originating and terminating > sides. On originating, if the request has a GRUU in the contact the > home proxy record routes. On terminating, it record routes if the > URI in the request URI is bound to a contact that has a GRUU. Other > proxies in the domain can do what they want. Some guidance is given > on what a proxy would see if it does or doesnt record route. > > * added rules for tel URI handling > > * removed bit about registering different contacts to each AOR when a > UA has multiple AOR; will leave that to the UA loose route spec > > * added requirement that contact cannot be weakly equivalent to AOR; > this deals with the GRUU loop problem (where a UA registers its own > GRUU as a contact with the instance ID associated with the GRUU, > causing the GRUU to resolve to itself). Previously, this was solved > by prohibiting the contact from being a GRUU. However, there are > valid cases for this when registering a instance in one domain to > another domain. This new rule allows this. I don't understand what is really meant by this paragraph: If, however, the GRUU was a public GRUU, the registrar SHOULD continue to treat the GRUU as valid. Consequently, subsequent requests targeted to the GRUU, prior to re-registration of a contact to the GRUU, SHOULD return a 480. In addition, since the GRUU remains valid, the rules in Section 5.1 will cause it to be retained when a contact with that instance ID is once again registered to the AOR. As described in this draft, a public gruu is just the AOR decorated with a 'gr' parameter with a value. If I'm not mistaken, that should be treated as equivalent to any undecorated version of that AOR according to 3261 URI equivalence rules, but not to any version of that AOR that has some other version of the 'gr' parameter. So wouldn't the same effect be achieved by just making the value of the 'gr' parameter be exactly the value of the +sip.instance value that was passed in the REGISTER request that created the public gruu? This would have the additional nice property that the UA is in control of when a public gruu is considered equivalent and when it is not, since it selects the +sip.instance value. Why prohibit the registrar from putting 'gruu' in the Supported header? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Sun Oct 29 16:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIB9-0006Lc-I4; Sun, 29 Oct 2006 16:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeIB8-0006LP-Kp for sip@ietf.org; Sun, 29 Oct 2006 16:26:50 -0500 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 1GeIB7-0007tj-Ay for sip@ietf.org; Sun, 29 Oct 2006 16:26:50 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id AC8B06FC; Sun, 29 Oct 2006 16:26:35 -0500 From: "Hadriel Kaplan" To: "'EKR'" , "'David R Oran'" Subject: RE: [Sip] RE: TLS meaning Date: Sun, 29 Oct 2006 16:26:23 -0500 Message-ID: <004401c6fba0$e2cbbd20$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb6lvk5wgru4K1ZQuuOE/jsTehb6gAL4GBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <864ptok1ir.fsf@raman.networkresonance.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "'Joel M. Halpern'" , 'IETF SIP List' , 'Paul Kyzivat' , 'Francois Audet' , '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: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Saturday, October 28, 2006 9:34 AM > >From a security perspective, SIPS has two important properties: > > 1. It says to the client "you MUST talk to me over SSL". I hope it doesn't say that. I thought we had to use TLS. ;) > 2. It says to the proxies "I expect you to make the outgoing > connection with TLS". > > As Samir has observed, the second property can be provided with some > indicator in the SIP header. However, the first can only be provided > by putting the indicator in the reference which you hand around (i.e., > the SIP URI). This isn't to say it necessarily has to be a new URI > scheme--though it did in HTTP because HTTP doesn't have > parameters--but it's not clear to me that moving it to parameters > would really help. I think the part some of us are worried about is it will inherit the perception of https: namely that the entire path from the caller to the answerer is secure. Just because an IETF doc says it's not the same, and says it's not a lock icon, will not overcome the perception. Even though an https connection is only secure to the TLS terminator (the server or an offloader), and the back-end from there is not, the assumption is the owner of the terminator takes on the responsibility from there (if there is any responsibility). And the terminator owner wanted to secure it between the browser and the terminator, and they got that. But SIP is neither HTTP nor SMTP. The sips uri may end at a pstn gateway, or an h323 IWF, or whatever. It may become sip later, as well. The owner of the TLS terminator does not necessarily equal the owner of the final UAS, nor the owner of the answerer. How can the owner of the terminator have any responsibility for something that may happen somewhere else, unbeknownst to him? How/why would someone who types in a sips uri for their request not think it's like https? In some ways the perception problem is exacerbated by the uri being the sips scheme. If it were a require/proxy-require instead, it would help alleviate that perception problem, IMO. But then you're left with trying such a request without the foreknowledge of success probability that a business-card sips address would give you. -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 Oct 29 17:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJS3-0002dR-IA; Sun, 29 Oct 2006 17:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOj-0005FC-Ps for sip@ietf.org; Sun, 29 Oct 2006 17:44:57 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJH5-0006Dt-3e for sip@ietf.org; Sun, 29 Oct 2006 17:37:07 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 62ED46C017; Sun, 29 Oct 2006 17:36:52 -0500 (EST) Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-03- From: Scott Lawrence To: EKR In-Reply-To: <20061029191627.3BD681CC22@delta.rtfm.com> References: <20061029191627.3BD681CC22@delta.rtfm.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 29 Oct 2006 17:36:58 -0500 Message-Id: <1162161418.24425.85.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Sun, 2006-10-29 at 11:16 -0800, EKR wrote: > The appropriate thing here seems to be to follow HTTPS practice. Each > domain has its own key pair and cert. The hosting service has the > private key. You use name-based virtual hosting if you can trust > clients to provide the dns_name. Otherwise you use IP-based. > > > The following rules seem appropriate: > 1. Nothing prohibits SIP servers certs from having multiple names. > 2. Clients should accept certificates with multiple names. > 3. Clients should deterministically check for the presence of > one name (the one in whatever they're dereferencing) and ignore > others. > 4. Servers which wish to act for multiple identities should either > (a) have a certificate with multiple names > (b) use some form of virtual hosting. > 5. Clients should generate the dns_name extension. > > Have I missed something? The essential thing about puting both the SIP domain name as a URI and the host name as a DNS name is to clarify the scope of the authority to use that name. I may deploy many services at 'example.com': SIP, DNS, HTTP, some illegal music sharing service, whatever.... at some point, I will want or need those services to be on different systems. I may want or need to even use different certificate hierarchies for different services. I want my SIP certificate to be able to express the statement "I am authoritative for the SIP domain 'example.com'", without making any statement about that server being authoritative for email to 'example.com'. Further, I may want to make that statement about servers that are the originators of connections but do not accept connections: I may have two proxies for outbound connections and two for inbound connections. Resolving 'example.com' using NAPTR/SRV will find only the inbound servers, but I still want to be able to assert that the outbound servers are authoritative for the domain (it's fine to bill me for the calls they originate, you can trust the identity headers they sign, etc). I do not want the fact that someone was able to create a host certificate for 'randomhost.example.com', even from the same certificate authority, to be accepted as an assertion of authority for my SIP services. That asymmetry doesn't occur in HTTP, so certificate usage in HTTP doesn't cover it. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Sun Oct 29 18:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeK1j-0006uW-1k; Sun, 29 Oct 2006 18:25:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeK0P-0006KP-An for sip@ietf.org; Sun, 29 Oct 2006 18:23:53 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeK0N-0003xY-Uw for sip@ietf.org; Sun, 29 Oct 2006 18:23:53 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F1F681E8C28; Sun, 29 Oct 2006 15:23:50 -0800 (PST) To: Scott Lawrence Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-03- References: <20061029191627.3BD681CC22@delta.rtfm.com> <1162161418.24425.85.camel@scott.skrb.org> From: Eric Rescorla Date: Sun, 29 Oct 2006 15:23:50 -0800 In-Reply-To: <1162161418.24425.85.camel@scott.skrb.org> (Scott Lawrence's message of "Sun, 29 Oct 2006 17:36:58 -0500") Message-ID: <86mz7eg0zd.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: 0a7aa2e6e558383d84476dc338324fab 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 Scott Lawrence writes: > On Sun, 2006-10-29 at 11:16 -0800, EKR wrote: > >> The appropriate thing here seems to be to follow HTTPS practice. Each >> domain has its own key pair and cert. The hosting service has the >> private key. You use name-based virtual hosting if you can trust >> clients to provide the dns_name. Otherwise you use IP-based. >> >> >> The following rules seem appropriate: >> 1. Nothing prohibits SIP servers certs from having multiple names. >> 2. Clients should accept certificates with multiple names. >> 3. Clients should deterministically check for the presence of >> one name (the one in whatever they're dereferencing) and ignore >> others. >> 4. Servers which wish to act for multiple identities should either >> (a) have a certificate with multiple names >> (b) use some form of virtual hosting. >> 5. Clients should generate the dns_name extension. >> >> Have I missed something? > > The essential thing about puting both the SIP domain name as a URI and > the host name as a DNS name is to clarify the scope of the authority to > use that name. I may deploy many services at 'example.com': SIP, DNS, > HTTP, some illegal music sharing service, whatever.... at some point, I > will want or need those services to be on different systems. I may want > or need to even use different certificate hierarchies for different > services. I want my SIP certificate to be able to express the statement > "I am authoritative for the SIP domain 'example.com'", without making > any statement about that server being authoritative for email to > 'example.com'. That's a reasonable theory, but it's not clear to me why you think this ought to be done with naming. ISTM that the right way to do this is with extendedkeyusage. > Further, I may want to make that statement about servers > that are the originators of connections but do not accept connections: I > may have two proxies for outbound connections and two for inbound > connections. Resolving 'example.com' using NAPTR/SRV will find only the > inbound servers, but I still want to be able to assert that the outbound > servers are authoritative for the domain (it's fine to bill me for the > calls they originate, you can trust the identity headers they sign, > etc). Right. Give them all a certificate for the name "example.com" with whatever "This is a SIP certificate" indicator we eventually choose. -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 Sun Oct 29 18:54:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeKR9-0003xq-Q6; Sun, 29 Oct 2006 18:51:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeKQH-0003Ts-Tq for sip@ietf.org; Sun, 29 Oct 2006 18:50:38 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeKQE-0007AG-FN for sip@ietf.org; Sun, 29 Oct 2006 18:50:37 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id k9TNoGaA000209; Sun, 29 Oct 2006 17:50:28 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 29 Oct 2006 17:50:20 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Oct 2006 00:50:18 +0100 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: TLS meaning Date: Mon, 30 Oct 2006 00:50:18 +0100 Message-ID: <5D1A7985295922448D5550C94DE2918069B44B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyA= From: "Drage, Keith \(Keith\)" To: "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 29 Oct 2006 23:50:18.0832 (UTC) FILETIME=[FD428D00:01C6FBB4] 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 As WG chair: Please bear in mind: 1) The WG agreed at the last meeting that the scope of this document is an informational document. The minutes clearly state this, and the charter as follows: Mar 2007 Guidelines for use of SIP security to WGLC (Informational) Jun 2007 Guidelines for use of SIP security to IESG (Informational) Was updated to say this. (Both these have been presented to the mailing list without comment in reasonable time so this as far as I am concerned is a decision. Therefore this document in itself does not deprecate SIPS, and we will need to decide to do this later. 2) This document does not update RFC 3261 it itself. Francois please update your abstract because this is not what this document does. You may also want to investigate the RFC 2119 language as a result. There will have to be other documents that update RFC3261 that are not this document. Note that we did agree that this document was the basis of this work, and therefore it should be reissued as a -00 SIP WG document. 3) What this document is/was intended to do was: - clearly document what we had now, i.e. identify what occurred if the user attempted xyd, and what level of security they did get if they attempted xyz. - identify what improvements or changes to our current SIP security, as defined in RFC 3261, where therefore required. These could fall into the following: A) creation of new mechanisms that provided a level of security that is not provided by the existing mechanisms. I this case we need to clearly identify the improvement and motivate why it is needed. B) changes to existing mechanisms to make them work. In this case, we need to clearly state why the existing mechanism is broken, i.e. not interoperable to produce a deterministic result. C) deprecation of existing mechanism - the one we seem to be discussing here. In this case, I (and we are the ones that have to justify this to the IESG) want to understand firstly why the existing mechanism is harmful to implementations if it continues to exist, and also understand the impact on the existing implementation community if we do deprecate. Therefore what this discussion must do is identify these reasons and put them in the document. Regards Keith > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 27 October 2006 17:12 > To: IETF SIP List > Subject: RE: [Sip] RE: TLS meaning >=20 > In case people having noticed, it is looking like we are=20 > having a mailing list hum on the following 2 questions: >=20 > 1 - Do you favour deprecating the sips scheme altogether (yes/no) >=20 > 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) >=20 >=20 > Note: Voting Yes on 2 does not necessarily imply you are=20 > voting No on 1, but it will only make sense if sips is not deprecated. >=20 > I'm keeping track of the vote. >=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 Sun Oct 29 21:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMk1-0007Nn-2c; Sun, 29 Oct 2006 21:19:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMU3-0003QE-5d for sip@ietf.org; Sun, 29 Oct 2006 21:02:39 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeMIg-0001bq-AR for sip@ietf.org; Sun, 29 Oct 2006 20:50:55 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9U1or5Y018501 for ; Sun, 29 Oct 2006 18:50:53 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 29 Oct 2006 18:50:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback Requested: draft-johns-sip-outbound-middialog Thread-Index: Acb7xdQgCDV8tLpjRyCJ3BbkuRtTmQ== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [Sip] Feedback Requested: draft-johns-sip-outbound-middialog X-BeenThere: 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="===============0264877947==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0264877947== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FBC5.D592672D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FBC5.D592672D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks,=20 =20 I originally sent this email on Friday, but did not see it on the reflector; so if this is a repeat, I apologize. =20 The topic of routing mid-dialog requests when using outbound procedures was documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-00 and subsequently presented at IETF#65 (see http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the meeting and other offline discussions, an updated Internet Draft was submitted and is now available at: =20 http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-draft-01 =20 The updates are primarily around clarifying the use case and illustrative call flow, the proposed solution has not changed. =20 The Abstract is reproduced for the benefit of folks not involved in earlier discussions: =20 " This document describes modifications to the procedures for the generation of a flow token as described in the Internet Draft titled Managing Client Initiated Connections in the Session Initiation Protocol. This modification is necessary to support routing of mid- dialog requests while preserving Edge Proxy failover within an outbound-proxy-set." =20 Would appreciate comments and interest. =20 Thanks Kevin =20 =20 ~~~~~~~~~~~~~~~~~~~~~~ Kevin C. Johns Project Director - PacketCable Communications Protocols CableLabs(r) 858 Coal Creek Circle Louisville, CO 80027-9750 Phone: 303.661.9100 Direct: 303.661.3303 HTTP://www.CableLabs.com =20 =20 ------_=_NextPart_001_01C6FBC5.D592672D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
I originally=20 sent this email on Friday, but did not see it on the reflector; so if = this is a=20 repeat, I apologize.
 
The=20 topic of routing mid-dialog requests when using outbound procedures was=20 documented in http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-dr= aft-00 and subsequently presented at IETF#65 (see = http://www3.ietf.org/proceedings/06jul/slides/sip-4.pdf ). Based on the feedback gathered at the meeting = and other=20 offline discussions, an updated Internet Draft was submitted and is now=20 available at:
 
http://tools.ietf.org/html/draft-johns-sip-outbound-middialog-dr= aft-01
 
The updates are primarily around = clarifying the use=20 case and illustrative call flow, the proposed solution has not=20 changed.
 
The Abstract is reproduced for the = benefit of folks=20 not involved in earlier discussions:
 
" This document describes modifications = to the=20 procedures for the
generation of a flow token as described = in the=20 Internet Draft titled
Managing Client Initiated Connections = in the=20 Session Initiation
Protocol. This modification is = necessary to support=20 routing of mid-
dialog requests while preserving Edge = Proxy=20 failover within an
outbound-proxy-set."
 
Would appreciate comments and=20 interest.
 
Thanks
Kevin
 
 

~~~~~~~~~~~~~~~~~~~~~~
Kevin C.=20 Johns
Project Director - PacketCable Communications=20 Protocols
CableLabs®
858 Coal Creek Circle
Louisville, CO=20 80027-9750
Phone:  303.661.9100
Direct: = 303.661.3303
HTTP://www.CableLabs.com =

 
------_=_NextPart_001_01C6FBC5.D592672D-- --===============0264877947== 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 --===============0264877947==-- From sip-bounces@ietf.org Sun Oct 29 21:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeN7K-0007Jb-CL; Sun, 29 Oct 2006 21:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeMtC-0008A7-KQ for sip@ietf.org; Sun, 29 Oct 2006 21:28:39 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeMt7-0008Mj-NH for sip@ietf.org; Sun, 29 Oct 2006 21:28:38 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 44D0D6C017; Sun, 29 Oct 2006 21:28:25 -0500 (EST) Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-03- From: Scott Lawrence To: EKR In-Reply-To: <86mz7eg0zd.fsf@raman.networkresonance.com> References: <20061029191627.3BD681CC22@delta.rtfm.com> <1162161418.24425.85.camel@scott.skrb.org> <86mz7eg0zd.fsf@raman.networkresonance.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 29 Oct 2006 21:28:30 -0500 Message-Id: <1162175310.24425.102.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Sun, 2006-10-29 at 15:23 -0800, Eric Rescorla wrote: > Scott Lawrence writes: > > > On Sun, 2006-10-29 at 11:16 -0800, EKR wrote: > > > >> The appropriate thing here seems to be to follow HTTPS practice. Each > >> domain has its own key pair and cert. The hosting service has the > >> private key. You use name-based virtual hosting if you can trust > >> clients to provide the dns_name. Otherwise you use IP-based. > >> > >> > >> The following rules seem appropriate: > >> 1. Nothing prohibits SIP servers certs from having multiple names. > >> 2. Clients should accept certificates with multiple names. > >> 3. Clients should deterministically check for the presence of > >> one name (the one in whatever they're dereferencing) and ignore > >> others. > >> 4. Servers which wish to act for multiple identities should either > >> (a) have a certificate with multiple names > >> (b) use some form of virtual hosting. > >> 5. Clients should generate the dns_name extension. > >> > >> Have I missed something? > > > > The essential thing about puting both the SIP domain name as a URI and > > the host name as a DNS name is to clarify the scope of the authority to > > use that name. I may deploy many services at 'example.com': SIP, DNS, > > HTTP, some illegal music sharing service, whatever.... at some point, I > > will want or need those services to be on different systems. I may want > > or need to even use different certificate hierarchies for different > > services. I want my SIP certificate to be able to express the statement > > "I am authoritative for the SIP domain 'example.com'", without making > > any statement about that server being authoritative for email to > > 'example.com'. > > That's a reasonable theory, but it's not clear to me why you think > this ought to be done with naming. ISTM that the right way to > do this is with extendedkeyusage. > > Further, I may want to make that statement about servers > > that are the originators of connections but do not accept connections: I > > may have two proxies for outbound connections and two for inbound > > connections. Resolving 'example.com' using NAPTR/SRV will find only the > > inbound servers, but I still want to be able to assert that the outbound > > servers are authoritative for the domain (it's fine to bill me for the > > calls they originate, you can trust the identity headers they sign, > > etc). > > Right. Give them all a certificate for the name "example.com" with > whatever "This is a SIP certificate" indicator we eventually > choose. Well, the idea in the draft is to use the fact that the URL has a 'sip' scheme to do just that. Is there some reason you can think of why something else is required? As far as I can tell, all that is needed is an unambiguous way to express what purpose the certificate is issued for that's easy for implementors to do and certification issuers can enforce. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Sun Oct 29 22:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeNMu-0005h7-JP; Sun, 29 Oct 2006 21:59:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeN5Y-0006RD-Q1 for sip@ietf.org; Sun, 29 Oct 2006 21:41:24 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeN5X-00026i-GE for sip@ietf.org; Sun, 29 Oct 2006 21:41:24 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BFC951E8C28; Sun, 29 Oct 2006 18:41:22 -0800 (PST) To: Scott Lawrence Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-03- References: <20061029191627.3BD681CC22@delta.rtfm.com> <1162161418.24425.85.camel@scott.skrb.org> <86mz7eg0zd.fsf@raman.networkresonance.com> <1162175310.24425.102.camel@scott.skrb.org> From: Eric Rescorla Date: Sun, 29 Oct 2006 18:41:22 -0800 In-Reply-To: <1162175310.24425.102.camel@scott.skrb.org> (Scott Lawrence's message of "Sun, 29 Oct 2006 21:28:30 -0500") Message-ID: <868xiybk4t.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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Scott Lawrence writes: > On Sun, 2006-10-29 at 15:23 -0800, Eric Rescorla wrote: >> Right. Give them all a certificate for the name "example.com" with >> whatever "This is a SIP certificate" indicator we eventually >> choose. > > Well, the idea in the draft is to use the fact that the URL has a 'sip' > scheme to do just that. Except that you've defined certificates that have two SANs, one SIP and one not. > Is there some reason you can think of why something else is > required? As far as I can tell, all that is needed is an unambiguous > way to express what purpose the certificate is issued for that's > easy for implementors to do and certification issuers can enforce. Right, but you realize that certificates already have a way to express uses using the extendedKeyUsage extension. So, I'm not at all sure that naming is what's appropriate here. That said, I'm not an expert on this. I would recommend asking PKIX what they like for denoting purpose. -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 Sun Oct 29 22:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeNtw-0004ri-5A; Sun, 29 Oct 2006 22:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeNfh-00042I-CN for sip@ietf.org; Sun, 29 Oct 2006 22:18:45 -0500 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeNfd-0008CP-42 for sip@ietf.org; Sun, 29 Oct 2006 22:18:45 -0500 Received: from localhost.localdomain (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 497166C017; Sun, 29 Oct 2006 22:18:30 -0500 (EST) Subject: Re: [Sip] Comments on draft-gurbani-sip-domain-certs-03- From: Scott Lawrence To: EKR In-Reply-To: <868xiybk4t.fsf@raman.networkresonance.com> References: <20061029191627.3BD681CC22@delta.rtfm.com> <1162161418.24425.85.camel@scott.skrb.org> <86mz7eg0zd.fsf@raman.networkresonance.com> <1162175310.24425.102.camel@scott.skrb.org> <868xiybk4t.fsf@raman.networkresonance.com> Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Sun, 29 Oct 2006 22:18:36 -0500 Message-Id: <1162178316.24425.107.camel@scott.skrb.org> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Sun, 2006-10-29 at 18:41 -0800, Eric Rescorla wrote: > Scott Lawrence writes: > > On Sun, 2006-10-29 at 15:23 -0800, Eric Rescorla wrote: > >> Right. Give them all a certificate for the name "example.com" with > >> whatever "This is a SIP certificate" indicator we eventually > >> choose. > > > > Well, the idea in the draft is to use the fact that the URL has a 'sip' > > scheme to do just that. > > Except that you've defined certificates that have two SANs, one SIP and > one not. > > > Is there some reason you can think of why something else is > > required? As far as I can tell, all that is needed is an unambiguous > > way to express what purpose the certificate is issued for that's > > easy for implementors to do and certification issuers can enforce. > > Right, but you realize that certificates already have a way to > express uses using the extendedKeyUsage extension. So, I'm > not at all sure that naming is what's appropriate here. That > said, I'm not an expert on this. I would recommend asking PKIX > what they like for denoting purpose. Yes, that would seem to be a good idea. For anyone interested, the relevant specs would appear to be RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" sections 4.2.1.7 Subject Alternative Name 4.2.1.13 Extended Key Usage The extended key usage is an OID that we define to mean whatever we decide it needs to mean, apparently. Does the SIP working group already have an OID root to hang this on? -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 Sun Oct 29 22:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeOEK-0002oq-Sd; Sun, 29 Oct 2006 22:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeO3k-0004A2-2H for sip@ietf.org; Sun, 29 Oct 2006 22:43:36 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeO3i-0004iU-8E for sip@ietf.org; Sun, 29 Oct 2006 22:43:36 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 81BBF20634 for ; Mon, 30 Oct 2006 09:08:07 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 6F66D20632 for ; Mon, 30 Oct 2006 09:08:07 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 09:13:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Oct 2006 09:13:25 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB0148@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb71TbpvTTWSdoPROmtdAZowBC7oA== From: To: X-OriginalArrivalTime: 30 Oct 2006 03:43:25.0738 (UTC) FILETIME=[8E1B08A0:01C6FBD5] X-Spam-Score: 0.4 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [Sip] Draft for review:draft-sreeram-specify-method-00.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="===============0300498000==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0300498000== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FBD5.8DD031AC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FBD5.8DD031AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 We have submitted a I-D regarding the Extension to the SIP to allow the=20 SIP entities intension of Asynchronous service change request. =20 The url of the draft is : http://www.ietf.org/internet-drafts/draft-sreeram-specify-method-00.txt =20 Please look at the draft and provide suggestions, comments and/or concerns. =20 =20 =20 Thanking you, =20 Regards, Sreeram. ------_=_NextPart_001_01C6FBD5.8DD031AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

=

We have submitted a I-D regarding = the Extension to the SIP to allow the

SIP entities intension of = Asynchronous service change request.

 

=

The url of the draft is = :

http://www.ietf.org/internet-drafts/= draft-sreeram-specify-method-00.txt

 

=

Please look at the draft and = provide suggestions, comments and/or concerns.        =

 

 

Thanking = you,

 

Regards,

Sreeram.

------_=_NextPart_001_01C6FBD5.8DD031AC-- --===============0300498000== 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 --===============0300498000==-- From sip-bounces@ietf.org Sun Oct 29 23:53:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeP6b-0004IS-3q; Sun, 29 Oct 2006 23:50:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeP5G-0002ll-0O for sip@ietf.org; Sun, 29 Oct 2006 23:49:14 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeP5E-0001Gd-Qh for sip@ietf.org; Sun, 29 Oct 2006 23:49:13 -0500 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <20061030044912013008unuue>; Mon, 30 Oct 2006 04:49: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 k9U4nCQg011276 for ; Sun, 29 Oct 2006 23:49:12 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id k9U4nBK0011272; Sun, 29 Oct 2006 23:49:11 -0500 Date: Sun, 29 Oct 2006 23:49:11 -0500 Message-Id: <200610300449.k9U4nBK0011272@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <8A24F115EA58164490CD026E9D0CEAD4AB0148@BLR-EC-MBX02.wipro.com> (sreeram.kanumuri@wipro.com) Subject: Re: [Sip] Draft for review:draft-sreeram-specify-method-00.txt References: <8A24F115EA58164490CD026E9D0CEAD4AB0148@BLR-EC-MBX02.wipro.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You write: Similarly, on restart/disconnect of a SIP entity without backup, the same problem exists and there is no way by which SIP entity that is restarting/disconnecting can inform about the alternative IP address (if available) to other SIP entities to which it can communicate so that graceful handling of existing sessions (or calls) or future sessions can be performed using alternate IP address. I don't understand what the "alternate IP address" can be -- you've already said the SIP entity does not have a backup, so there can be no alternate IP address at which to contact the backup. 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 Oct 30 03:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSd2-0006F9-IA; Mon, 30 Oct 2006 03:36:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeSd1-0006Cr-0Q for sip@ietf.org; Mon, 30 Oct 2006 03:36:19 -0500 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 1GeScx-0000b9-4I for sip@ietf.org; Mon, 30 Oct 2006 03:36:18 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7X00E8IX8H61@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Oct 2006 08:36:17 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LGZXG7>; Mon, 30 Oct 2006 08:36:05 +0000 Content-return: allowed Date: Mon, 30 Oct 2006 08:36:02 +0000 From: "Elwell, John" Subject: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F26670A38D7FD@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: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some of the discussion on the long thread on "TLS meaning" has led me to seek opinions on what does indeed control the lock icon, since we seem to have consensus that a successful SIPS request is not grounds for showing the lock icon. The user surely will expect media to be secured end-to-end. By end-to-end, I mean at least as far as the domain the user believes he/she is in communication with. So there has to be some cryptographic assurance that the entity with which the UA agrees keys for media security has the credentials of the entity indicated by caller or connected party identity (From+Identity or possibly PAI). This is probably a sufficient condition if key agreement is carried out using D-H. If the key is transported, then an additional condition is that the key is end-to-end encrypted, which for SDescriptions means encrypted using S/MIME. But what about the presence of B2BUAs, SBCs, etc. that do not have the credentials of the end user but nevertheless terminate media security? Here the UA could find that it does media negotiation with service-provider.net rather than with the end user (user@example.com). It seems the lock item should not be displayed in this situation. Or maybe the user could be consulted whether he/she accepts the certificate of the intermediary even though it fails to identify the remote user. Another situation is where a user is trying to contact +123456789@example.com but gets back a From/Identity indicating +123456789@service-provider.net and media is secured as far as service-provider.net. Does this constitute grounds for displaying the icon? John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 29 October 2006 21:26 > To: 'EKR'; 'David R Oran' > Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > 'Francois Audet'; 'Dean Willis' > Subject: RE: [Sip] RE: TLS meaning > > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: Saturday, October 28, 2006 9:34 AM > > >From a security perspective, SIPS has two important properties: > > > > 1. It says to the client "you MUST talk to me over SSL". > > I hope it doesn't say that. I thought we had to use TLS. ;) > > > > 2. It says to the proxies "I expect you to make the outgoing > > connection with TLS". > > > > As Samir has observed, the second property can be provided with some > > indicator in the SIP header. However, the first can only be provided > > by putting the indicator in the reference which you hand > around (i.e., > > the SIP URI). This isn't to say it necessarily has to be a new URI > > scheme--though it did in HTTP because HTTP doesn't have > > parameters--but it's not clear to me that moving it to parameters > > would really help. > > I think the part some of us are worried about is it will inherit the > perception of https: namely that the entire path from the > caller to the > answerer is secure. Just because an IETF doc says it's not > the same, and > says it's not a lock icon, will not overcome the perception. > Even though an > https connection is only secure to the TLS terminator (the > server or an > offloader), and the back-end from there is not, the > assumption is the owner > of the terminator takes on the responsibility from there (if > there is any > responsibility). And the terminator owner wanted to secure > it between the > browser and the terminator, and they got that. > > But SIP is neither HTTP nor SMTP. The sips uri may end at a > pstn gateway, > or an h323 IWF, or whatever. It may become sip later, as > well. The owner > of the TLS terminator does not necessarily equal the owner of > the final UAS, > nor the owner of the answerer. How can the owner of the > terminator have any > responsibility for something that may happen somewhere else, > unbeknownst to > him? How/why would someone who types in a sips uri for their > request not > think it's like https? > > In some ways the perception problem is exacerbated by the uri > being the sips > scheme. If it were a require/proxy-require instead, it would > help alleviate > that perception problem, IMO. But then you're left with trying such a > request without the foreknowledge of success probability that a > business-card sips address would give you. > > -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 Mon Oct 30 06:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVWR-00031N-BF; Mon, 30 Oct 2006 06:41:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeVW6-00030I-U7 for sip@ietf.org; Mon, 30 Oct 2006 06:41:23 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeVW4-0006oC-FU for sip@ietf.org; Mon, 30 Oct 2006 06:41:22 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7FF033BEB0 for ; Mon, 30 Oct 2006 12:41:05 +0100 (CET) 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 13899-01-10 for ; Mon, 30 Oct 2006 12:41:05 +0100 (CET) Received: from itft (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 109C13BE86 for ; Mon, 30 Oct 2006 12:41:04 +0100 (CET) Message-ID: <06c601c6fc18$432daf80$191e0bc1@it.su.se> From: "Fredrik Thulin" To: Date: Mon, 30 Oct 2006 12:40:55 +0100 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.2962 X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.562 tagged_above=-99 required=7 tests=[AWL=0.103, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] One big concern with outbound-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 While I am generally very much in favour of draft-Outbound, I have one big concern with it. I also have some other questions/comments after thoroughly reading version 05, but I will separate them from this first big concern and send them in another e-mail. My concern is that you, in your attempts to make sure outbound works with several layers of NATs/SIP stateful packet inspecting firewalls, you actually _break_ some otherwise perfectly fine resilient SIP network designs. Consider the following example in which every entity except the UA has a globally reachable IP address : ep1.isp.net (ep1.sip-p.net) UA --NAT-- ------- ep.sip-p.net -- Authoritative proxy / ep2.isp.net (ep2.sip-p.net) registrar The user agent has been provisioned with two Outbound URLs, sip:ep1.isp.net;keepalive=stun and sip:ep2.isp.net;keepalive=stun. The SIP service provider sip-p.net has two edge proxys of it's own, which the NAPTR records for sip-p.net directs all incoming traffic for sip-p.net to. Now, the UA opens one flow to ep1.isp.net, and one flow to ep2.isp.net. These are Outbound flows, so STUN keepalives are used to keep the connections alive etc. UA sends one REGISTER over it's first flow, and one over it's second. ep1.isp.net and ep2.isp.net resolve the NAPTR records for sip-p.net, find that there are two hosts to which requests can be sent, and by coincidence both choose to send the REGISTER to ep1.sip-p.net. The REGISTERs contain Path headers, according to Outbound-05, so that requests sent towards the UA will travel in the reverse direction of the REGISTER, but on the exact same flows, for all the hops between the Authroitative proxy and the UA. Now, the registrar for sip-p.net has two bindings with the same instance-id, but different reg-id's, but both of these depend on the flow from ep1.sip-p.net to the registrar being alive! If ep1.sip-p.net goes down, then the authoritative proxy has no way of reaching the UA _because of restrictions introduced by Outbound_. If Outbound permitted, the UA could still be reached because both ep1.isp.net and ep2.isp.net is globally reachable. I STRONGLY object to the principle in Outbound that when a request is received destined for the UA, the proxys on the way MUST use the very same connection on every hop. On the last hop (between ep1/ep2.isp.net and the UA), naturally the same flow has to be used, but not for example between the EP's of isp.net and sip-p.net! It is not at all unreasonable that practically all SIP servers have global connectivity, even though clearly it was not reasonable to expect all user agents to have one. I'm going to stop now before this e-mail gets too long for anyone to read on an IETF mailing list, but if anyone have a question about anything I've written above, then please ask and I will try to clarify. /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 Oct 30 08:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXMK-0003qz-Ag; Mon, 30 Oct 2006 08:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXLt-0003Xq-8r for sip@ietf.org; Mon, 30 Oct 2006 08:38:57 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeXLr-0007FR-KU for sip@ietf.org; Mon, 30 Oct 2006 08:38:57 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id BBCEC3BEEE for ; Mon, 30 Oct 2006 14:38:40 +0100 (CET) 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 26304-01-97 for ; Mon, 30 Oct 2006 14:38:40 +0100 (CET) Received: from itft (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 4FDCF3BE8A for ; Mon, 30 Oct 2006 14:38:40 +0100 (CET) Message-ID: <079301c6fc28$afe2b700$191e0bc1@it.su.se> From: "Fredrik Thulin" To: References: <06c601c6fc18$432daf80$191e0bc1@it.su.se> Subject: Re: [Sip] One big concern with outbound-05 Date: Mon, 30 Oct 2006 14:38:30 +0100 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-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.562 tagged_above=-99 required=7 tests=[AWL=0.103, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fredrik Thulin wrote: ... > I STRONGLY object to the principle in Outbound that when a request is > received destined for the UA, the proxys on the way MUST use the very > same connection on every hop. On the last hop (between ep1/ep2.isp.net > and the UA), naturally the same flow has to be used, but not for > example between the EP's of isp.net and sip-p.net! It is not at all > unreasonable that practically all SIP servers have global > connectivity, even though clearly it was not reasonable to expect all > user agents to have one. I think I will have to take all of this back. When going through my print out of the draft with comments in the margins, to write about the other questions/comments I had I think I realize that you actually _have_ loosened the rules in outbound-05 to not demand proxys with global reachability to use the very same flow. Can I just verify this by asking if the following scenario would work with Outbound-05? ep1.isp.net (ep1.sip-p.net) UA --NAT-- ------- ep.sip-p.net -- Authoritative proxy / ep2.isp.net (ep2.sip-p.net) registrar The UA sets up one Outbound flow to ep1.isp.net, and one to ep2.isp.net. It sends a REGISTER on both flows, and when these reach the Authoritative proxy / registrar they look like this : Request #1 : REGISTER sip:sip-p.net Via: SIP/2.0/TCP ep1.isp.net;branch=... Via: SIP/2.0/TCP ep1.sip-p.net;branch=... Path: From: <...> ... Request #2 : REGISTER sip:sip-p.net Via: SIP/2.0/TCP ep2.isp.net;branch=... Via: SIP/2.0/TCP ep1.sip-p.net;branch=... Path: From: <...> ... So the edge proxys of sip-p.net didn't add any Path headers, because they knew that ep1.isp.net was globally reachable, and the Authoritative proxy didn't add itself to the Path vector before storing the location binding? If this is how it would work, then I am totally happy with it. /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 Oct 30 09:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXte-0002B9-4Q; Mon, 30 Oct 2006 09:13:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeXtV-0002Aa-TR for sip@ietf.org; Mon, 30 Oct 2006 09:13:41 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeXtO-00040f-QL for sip@ietf.org; Mon, 30 Oct 2006 09:13:41 -0500 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 k9UEDTj17385; Mon, 30 Oct 2006 09:13:29 -0500 (EST) 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] New I-D on UA loose routing Date: Mon, 30 Oct 2006 08:13:27 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371112CFFE2@zrc2hxm2.corp.nortel.com> In-Reply-To: <452FC0B7.6030007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on UA loose routing Thread-Index: Acbu5nuIMr3XDWmIRD6vj3qblkNDpwNRsTRA From: "Brian Stucker" To: "Jonathan Rosenberg" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Another idea to add to this topic... Why not do something like this: Contact: ...when handing out a URI, so that when someone creates an INVITE based off of that contact they wind up generating: INVITE sip:user@domain SIP/2.0 Opaque-Params: blah Etc. That should survive all the way to the other side. Regards, Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Friday, October 13, 2006 11:37 AM > To: IETF SIP List > Subject: [Sip] New I-D on UA loose routing >=20 > I've submitted a new I-D which describes this concept of UA=20 > loose routing that we've been discussing on the list. This=20 > fell out of the GRUU discussions as an alternative solution=20 > for grid. As the draft explains, the mechanism also solves=20 > many other problems, like sub-addressing, limited use=20 > adresses, 8xx number usage, and is even required for proper=20 > 911/emergency services operation with ecrit. >=20 > Until the draft appears in the archives, you can pick it up at: > http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-rou te-00.txt >=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=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 Oct 30 09:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYLI-0003pl-Ci; Mon, 30 Oct 2006 09:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYLG-0003pd-CR for sip@ietf.org; Mon, 30 Oct 2006 09:42:22 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYLC-0008Ji-Qw for sip@ietf.org; Mon, 30 Oct 2006 09:42:22 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 879913BEC7 for ; Mon, 30 Oct 2006 15:41:55 +0100 (CET) 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 03261-01-58 for ; Mon, 30 Oct 2006 15:41:55 +0100 (CET) Received: from itft (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id D8F633BE23 for ; Mon, 30 Oct 2006 15:41:54 +0100 (CET) Message-ID: <07b501c6fc31$85957740$191e0bc1@it.su.se> From: "Fredrik Thulin" To: Date: Mon, 30 Oct 2006 15:41:44 +0100 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.2962 X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.563 tagged_above=-99 required=7 tests=[AWL=0.102, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Sip] Comments on draft-ietf-sip-outbound-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 other comments/questions on Outbound 05 : > 5.1 Processing Register Requests > > When an Edge Proxy receives a registration request with a reg-id > header parameter in the Contact header field, it typically needs to > store a "flow token", containing information about the flow from > the > previous hop, in a Path header field value as described in RFC 3327 > [RFC3327]. I would like to suggest making this text clearer about when an edge proxy needs to store a flow token and when it does not have to. Suggestion : "When an Edge Proxy receives a registration request with a reg-id header parameter in the Contact header field, it must determine if it (the edge proxy) will have to be visited for any subsequent requests sent to the user agent identified in the Contact header field, or not. If the Edge Proxy determines that this is the case, then it needs to store a "flow token", containing information about the flow from the previous hop, in a Path header field value as described in RFC 3327 [RFC3327]." > 5.3 Forwarding Requests > > Otherwise, if the top- > most Route header refers to the Edge Proxy and contains a valid > flow > identifier token created by this proxy, the proxy MUST remove the > the > Route header and forward the request over the flow that received > the > REGISTER request that caused the flow identifier token to be > created. I suggest the following sentence instead : "Otherwise, if the top-most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the flow identified by the flow token". If you don't like my text, then at least note there is a "the the" in the original sentence. > 6. Registrar Mechanisms: Processing REGISTER Requests > > Likewise if > the REGISTER request visited an edge proxy, but no Path header > field > values are present, the registrar MUST ignore the reg-id parameter. Just to check: Would a registrar know this because there were more than one Via header in the request, but no Path header? > 6. Registrar Mechanisms: Processing REGISTER Requests > > For a binding with an > instance-id, the registrar still stores the Contact header field > value URI with the binding, but does not consider the Contact URI > for > comparison purposes. Shouldn't that be "For a binding with an instance-id and a reg-id, the ..."? > 6. Registrar Mechanisms: Processing REGISTER Requests > > In addition to the normal information stored in the binding record, > some additional information needs to be stored for any registration > that contains a reg-id header parameter in the Contact header field > value. This should be "contains an instance-id and a reg-id header parameter" I believe. If there was only a reg-id parameter, it should be ignored. > 6. Registrar Mechanisms: Processing REGISTER Requests > > ... MUST implement support the STUN Either implement or support. > 7. Authoritative Proxy Mechansims: Forwarding Requests > > The proxy uses normal forwarding rules looking at the next-hop > target > of the message and the value of any stored Path header field vector > in the registration binding to decide how to forward the request > and > populate the Route header in the request. Additionally, when the > proxy forwards a request to a binding that contains a reg-id, if > the > binding has a previous hop flow associated with it, the proxy MUST > send the request over the same network flow that was saved with the > binding. This was one of the parts that was not clear enough for me to understand that the authoritative proxy could actually have decided that it didn't need to send the request using the exact same flow. I would like to suggest the following modification : "The proxy uses normal forwarding rules looking at the next-hop target of the message and the value of any stored Path header field vector in the registration binding to decide how to forward the request and populate the Route header in the request. If the proxy stored information about the flow it received the REGISTER for the binding in question over, then the proxy MUST send the request over the same network flow that was saved with the binding. The proxy would only have stored information about the exact flow used if it was deemed necessary at the time of registration, because the next hop was not known to be globally reachable." > 8. STUN Keepalive Processing > > Note that UACs MUST NOT > use an ambiguous configuration option such as "Work through NATs?" > or > "Do Keepalives?" to imply next hop STUN support. I think this sentence should be removed. I don't think there is a single way to ask the end user if STUN keepalives should be sent or not that would actually make sense to an average end user. That sentence is no longer needed after the new text explaining that a user agent must actually verify STUN support. I also think it is out of scope for Outbound to tell implementors how they should make their user interfaces. > 8. STUN Keepalive Processing Generally regarding the mechanisms in this section, I am a bit unsure about if the case where a next-hop actually _stops_ supporting STUN is handled with enough care. One might say that it would be very seldom that providers actually downgrade their edge proxys to something that no longer supports STUN, but think for example if I have my wifi phone configured with 192.168.0.1 supporting STUN keepalives. That might work just fine with my own wireless access point, but perhaps not with someone elses, that my phone ends up connected to. I think there should be text saying that support has to be re-verified after some period of time without successfull STUN transactions. Perhaps something like : "If a destination previously validated to support STUN keepalives does not respond to any STUN keepalives sent for 36000 seconds (ten hours), then the validation is to be considered revoked and support will have to be verified in the same way as if the next-hop had never been validated." > 8. STUN Keepalive Processing If a client sends a REGISTER with "Supported: path", and receives a 200 response with a Path vector in it, it could look for ";ob" in the first Path header value, and use that as an explicit indication that it would be OK to send STUN messages to the next hop, right? Of course, the text in this section about actually validating STUN support fot the next hop still applies. /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 Oct 30 10:27:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYzQ-0003lW-B3; Mon, 30 Oct 2006 10:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeYz9-0003Wz-1D for sip@ietf.org; Mon, 30 Oct 2006 10:23:35 -0500 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeYxc-0003QV-GQ for sip@ietf.org; Mon, 30 Oct 2006 10:22:04 -0500 Received: by wr-out-0506.google.com with SMTP id i5so235084wra for ; Mon, 30 Oct 2006 07:21:59 -0800 (PST) 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=ELbLn9i8NFn4Xy1f61KeSajVNKb0Pij45VD5P7EWAKtrsGE0UEqhMp8YFhbc9sECR+Z/F8dGG2un2pItr1EdeSArsveZnG0V7udp0lJYAFnnVuTnuhRkO7VF2srN7+ZY5tesFWMRlj9InZQ+9PgbJk8IjvPfXkc3oI/wuLM3P6Y= Received: by 10.78.97.7 with SMTP id u7mr5005197hub; Mon, 30 Oct 2006 07:21:58 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 30 Oct 2006 07:21:57 -0800 (PST) Message-ID: <953beacc0610300721x513a8296gf70df33d2eca2afb@mail.gmail.com> Date: Mon, 30 Oct 2006 07:21:58 -0800 From: "Rohan Mahy" To: "Jonathan Rosenberg" Subject: Re: [Sip] New I-D on UA loose routing In-Reply-To: <4541343D.3080908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <452FC0B7.6030007@cisco.com> <953beacc0610241526g5c3793e2y19f3f17e581d4be3@mail.gmail.com> <4541343D.3080908@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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, First I'd like to propose a concrete counter proposal. Dean would call this an additional "band-aid" but I feel like the patient has painfully managed to recover pretty well from 2nd degree burns over 60% of the body and now just has a persistent paper cut. We define a new URI parameter called 'ua-opaque'. When an authoritative proxy receives a request with this parameter in the request URI (in an AOR or a GRUU), it copies the value of this parameter into any URI it retargets to. This functionality is mandatory for URIs which are GRUU. This parameter effectively replaces the 'grid' parameter by providing a simple superset of the functionality. I believe that this approach has significantly better backwards compatility and maturity than the UA loose-route approach. Below I will list the technical problems I see with the UA loose route approach. 1) Outbound. the current outbound draft has language about what the first edge proxy needs to do. One of the ways to tell if the first proxy did its job is to check the first element in the Path vector for the 'ob' parameter. I don't believe this would work anymore. Maybe I am not smart enough, but I can't think of a way to make detection that outbound will work in a UA loose-route environment, short of a first-hop Proxy-Require, which a number of folks where adamantly against. 2) Forking / HERFP. There are some UAs which reject requests to them with Route headers left with a 400 and some with a 403. To be safe, a proxy will need to forward in the traditional manner to non-loose-route UAs, or risk exacerbating HERFP. A proxy forking to both UA loose-route and non-UA loose UAs therefore needs to keep track of both and effectively run two separate code paths for different branches for the same target set. 3) Marid-style assumptions. Like the problem with outbound, a proxy that wants to check that requests are either for its domain or from its domain and that it is receiving requests for its domain directly (not through an intervening proxy) may have a harder time figuring out if it is the first proxy. thanks, -rohan On 10/26/06, Jonathan Rosenberg wrote: > You are equating processing a Route header, with being a proxy. Nothing > in RFC 3261 says that if you process a Route header, you are a proxy. > Indeed, RFC 3261 is silent on the applicability of Route headers to UA. > Certainly I agree we don't want to require a UA to do thigns like mutual > TLS. > > Indeed, I would like to understand what concrete problems you see. Your > note points out that there could be other solutions, and then complains > that this is making things confusing. Yes, there could be other > solutions - I look forward to your draft. I don't think it makes things > more confusing. > > I think this mechanism is quite elegant in that extends the idea of > loose routing to UA, and is arguably what we should have done in SIP in > the first place. > > -Jonathan R. > > > > > > Rohan Mahy wrote: > > > Hi, > > > > I have read this draft and I think it is a terrible idea in SIP/2.0 to > > send a UA an incoming request with a Route header. If we were working > > on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea > > to consider as baseline behavior, but I think this is too major of a > > change from the current spec and state of implementation. > > > > Lets analyze the requirements described in the document. The unkown > > gruu, limited-use gruu, subaddressing, and service invocation > > requirements can all be met just by restoring the grid parameter to > > its rightful place in GRUU. The emergency services requirement is a > > tautology; if a proxy wants to rewrite the Request-URI from an SOS > > URN, don't do that, insert a loose-route instead; no additional > > mechanism or specification is necessary. The freephone requirement > > deals with mixed SIP and PSTN networks, where the existing > > History-Info (or dare I say Diversion) mechanism is perfectly adequate > > and more likely to be implemented in this environment. The alias > > requirement can be addresses in a variety of ways including > > configuration, or simply restoring the To header to usefulness. My > > conclusion is that this mechanism does not solve any requirements we > > are not already addressing. (If we were starting from scratch, we > > might do things differently). > > > > As for the implications of handling loose-routing on the UA, I do not > > believe the expected behavior is easily containable. The only entities > > that should receive requests with additional Route headers are proxy > > servers. Embedding a proxy server in/on a UA then requires the UA to > > implement TLS, strict route fix ups, loop detection, and a host of > > other things. I don't think we want to go there. The alternative is > > for us to break the rules and define a "sort of a proxy" role. I > > expect picking apart what parts of RFC3261 need to be implemented as a > > proxy would be a nightmare. I can also imagine the impact on the > > outbound draft if each outbound UA needs to route through an embeded > > edge proxy. How will the first "real" edge proxy decide if outbound > > processing has been done correctly? > > > > The concept of logical roles such as proxy, registrar, identity > > server, etc. is already confusing to many implementors. If we start > > redefining or breaking the rules which describe existing roles, I > > believe we are going to have a real mess on our hands. > > > > thanks, > > -rohan > > > > > > > > On 10/13/06, Jonathan Rosenberg wrote: > > > >> I've submitted a new I-D which describes this concept of UA loose > >> routing that we've been discussing on the list. This fell out of the > >> GRUU discussions as an alternative solution for grid. As the draft > >> explains, the mechanism also solves many other problems, like > >> sub-addressing, limited use adresses, 8xx number usage, and is even > >> required for proper 911/emergency services operation with ecrit. > >> > >> Until the draft appears in the archives, you can pick it up at: > >> http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt > >> > >> 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 Mon Oct 30 11:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZYO-0004Km-WE; Mon, 30 Oct 2006 11:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZYN-0004Kf-Cl for sip@ietf.org; Mon, 30 Oct 2006 10:59:59 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZYI-0003co-Vm for sip@ietf.org; Mon, 30 Oct 2006 10:59:59 -0500 Received: by ug-out-1314.google.com with SMTP id 72so991800ugd for ; Mon, 30 Oct 2006 07:59:54 -0800 (PST) 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=U8XCQYmEr9yJdr8pL19xq7fftmsHeIyi/+Os3f3Y6DZXdKCFDrg/qSz7YeoRd1+xyQaMerG4XaD8h7b8tVmMmCN8OKoblnTftFYhbSEClxLyDE5mmAR2Rii+w5avVxLkpah24B3g6245vsm/fIbtvulX0LU+BWhqQbijdZ0f1tQ= Received: by 10.78.151.15 with SMTP id y15mr5103544hud; Mon, 30 Oct 2006 07:59:52 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 30 Oct 2006 07:59:52 -0800 (PST) Message-ID: <953beacc0610300759m53fe3846ocda26af8de6b6f8e@mail.gmail.com> Date: Mon, 30 Oct 2006 07:59:52 -0800 From: "Rohan Mahy" To: "Fredrik Thulin" Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05 In-Reply-To: <07b501c6fc31$85957740$191e0bc1@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <07b501c6fc31$85957740$191e0bc1@it.su.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Fredrik, I like your proposed text. I'm pasting all these into the draft unless otherwise noted. On 10/30/06, Fredrik Thulin wrote: > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > Likewise if > > the REGISTER request visited an edge proxy, but no Path header > > field > > values are present, the registrar MUST ignore the reg-id parameter. > > Just to check: Would a registrar know this because there were more than > one Via header in the request, but no Path header? Yes. > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > For a binding with an > > instance-id, the registrar still stores the Contact header field > > value URI with the binding, but does not consider the Contact URI > > for > > comparison purposes. > > Shouldn't that be "For a binding with an instance-id and a reg-id, the > ..."? No, this sentence was added to allow implementations to fetch a GRUU (which needs an instance-id) without implementing outbound (which needs a reg-id). > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > In addition to the normal information stored in the binding record, > > some additional information needs to be stored for any registration > > that contains a reg-id header parameter in the Contact header field > > value. > > This should be "contains an instance-id and a reg-id header parameter" I > believe. If there was only a reg-id parameter, it should be ignored. Yes, good catch. > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > ... MUST implement support the STUN > > Either implement or support. "MUST implement the STUN keepalive mechanism described in Section x of this document." > > 8. STUN Keepalive Processing > > > > Note that UACs MUST NOT > > use an ambiguous configuration option such as "Work through NATs?" > > or > > "Do Keepalives?" to imply next hop STUN support. > > I think this sentence should be removed. I don't think there is a single > way to ask the end user if STUN keepalives should be sent or not that > would actually make sense to an average end user. That sentence is no > longer needed after the new text explaining that a user agent must > actually verify STUN support. I also think it is out of scope for > Outbound to tell implementors how they should make their user > interfaces. I added this at the request of other folks in the WG. The normative language is just "MUST NOT use an ambiguous configuration option". I'm inclined to leave this sentence or reword it unless the folks who were originally concerned also no longer think it is necessary. > > 8. STUN Keepalive Processing > > Generally regarding the mechanisms in this section, I am a bit unsure > about if the case where a next-hop actually _stops_ supporting STUN is > handled with enough care. One might say that it would be very seldom > that providers actually downgrade their edge proxys to something that no > longer supports STUN, but think for example if I have my wifi phone > configured with 192.168.0.1 supporting STUN keepalives. That might work > just fine with my own wireless access point, but perhaps not with > someone elses, that my phone ends up connected to. > > I think there should be text saying that support has to be re-verified > after some period of time without successfull STUN transactions. Perhaps > something like : > > "If a destination previously validated to support STUN keepalives does > not respond to any STUN keepalives sent for 36000 seconds (ten hours), > then the validation is to be considered revoked and support will have to > be verified in the same way as if the next-hop had never been > validated." Ugh. I'd like to think about this a bit more. > > 8. STUN Keepalive Processing > > If a client sends a REGISTER with "Supported: path", and receives a 200 > response with a Path vector in it, it could look for ";ob" in the first > Path header value, and use that as an explicit indication that it would > be OK to send STUN messages to the next hop, right? Of course, the text > in this section about actually validating STUN support fot the next hop > still applies. Probably, but I needed to make the section on STUN processing relatively autonomous. I think I will bring this up at the meeting. 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 Oct 30 11:07:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZdT-0007U5-Q2; Mon, 30 Oct 2006 11:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZdR-0007Tz-Nm for sip@ietf.org; Mon, 30 Oct 2006 11:05:13 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZdN-0005Ll-Ar for sip@ietf.org; Mon, 30 Oct 2006 11:05:13 -0500 Received: by ug-out-1314.google.com with SMTP id 72so993116ugd for ; Mon, 30 Oct 2006 08:05:08 -0800 (PST) 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=XSUrWQ2rUMGegnQJQY5qkqQiztu8s9ugzrlOGR7m8euevXyzPHovjeVV3qWZuEoxLIBQ+2cSQvDwLFPBmo2qsfK70xRV0Jkq0aNkPHVeLQw2GapQC/chSGSExXD4k1ViQb0NB+IXhKqvlGCnh9NYO9bMd1Ap1EVIe2qUCPTz1D8= Received: by 10.78.150.7 with SMTP id x7mr5115937hud; Mon, 30 Oct 2006 08:05:07 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 30 Oct 2006 08:05:06 -0800 (PST) Message-ID: <953beacc0610300805k27a8e5ffq261949577b25f22b@mail.gmail.com> Date: Mon, 30 Oct 2006 08:05:07 -0800 From: "Rohan Mahy" To: "Fredrik Thulin" Subject: Re: [Sip] One big concern with outbound-05 In-Reply-To: <079301c6fc28$afe2b700$191e0bc1@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <06c601c6fc18$432daf80$191e0bc1@it.su.se> <079301c6fc28$afe2b700$191e0bc1@it.su.se> 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 Fredrik, Yes, the scenario you described will work. thanks, -rohan On 10/30/06, Fredrik Thulin wrote: > Fredrik Thulin wrote: > ... > > I STRONGLY object to the principle in Outbound that when a request is > > received destined for the UA, the proxys on the way MUST use the very > > same connection on every hop. On the last hop (between ep1/ep2.isp.net > > and the UA), naturally the same flow has to be used, but not for > > example between the EP's of isp.net and sip-p.net! It is not at all > > unreasonable that practically all SIP servers have global > > connectivity, even though clearly it was not reasonable to expect all > > user agents to have one. > > I think I will have to take all of this back. When going through my > print out of the draft with comments in the margins, to write about the > other questions/comments I had I think I realize that you actually > _have_ loosened the rules in outbound-05 to not demand proxys with > global reachability to use the very same flow. > > Can I just verify this by asking if the following scenario would work > with Outbound-05? > > > ep1.isp.net (ep1.sip-p.net) > UA --NAT-- ------- ep.sip-p.net -- Authoritative proxy / > ep2.isp.net (ep2.sip-p.net) registrar > > > The UA sets up one Outbound flow to ep1.isp.net, and one to ep2.isp.net. > It sends a REGISTER on both flows, and when these reach the > Authoritative proxy / registrar they look like this : > > Request #1 : > > REGISTER sip:sip-p.net > Via: SIP/2.0/TCP ep1.isp.net;branch=... > Via: SIP/2.0/TCP ep1.sip-p.net;branch=... > Path: > From: <...> > ... > > Request #2 : > > REGISTER sip:sip-p.net > Via: SIP/2.0/TCP ep2.isp.net;branch=... > Via: SIP/2.0/TCP ep1.sip-p.net;branch=... > Path: > From: <...> > ... > > So the edge proxys of sip-p.net didn't add any Path headers, because > they knew that ep1.isp.net was globally reachable, and the Authoritative > proxy didn't add itself to the Path vector before storing the location > binding? > > If this is how it would work, then I am totally happy with it. > > /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 Mon Oct 30 11:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZmH-0006Ab-Ei; Mon, 30 Oct 2006 11:14:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZmF-0006AT-Nx for sip@ietf.org; Mon, 30 Oct 2006 11:14:19 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZmA-00086R-Jx for sip@ietf.org; Mon, 30 Oct 2006 11:14:19 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id BB87D3BE21; Mon, 30 Oct 2006 17:14:01 +0100 (CET) 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 15632-01-63; Mon, 30 Oct 2006 17:14:01 +0100 (CET) Received: from itft (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 59EBA3BEC3; Mon, 30 Oct 2006 17:14:01 +0100 (CET) Message-ID: <07ff01c6fc3e$639419a0$191e0bc1@it.su.se> From: "Fredrik Thulin" To: "Rohan Mahy" References: <06c601c6fc18$432daf80$191e0bc1@it.su.se><079301c6fc28$afe2b700$191e0bc1@it.su.se> <953beacc0610300805k27a8e5ffq261949577b25f22b@mail.gmail.com> Subject: Re: [Sip] One big concern with outbound-05 Date: Mon, 30 Oct 2006 17:13:50 +0100 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-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.563 tagged_above=-99 required=7 tests=[AWL=0.102, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Rohan Mahy wrote: > Hi Fredrik, > > Yes, the scenario you described will work. Thanks - then I'm very happy with the current Outbound. Just to double check, it will work without requests forwarded from the Authoritative proxy, towards the UA, going through the edge proxy of sip-p.net? I mean, ep1.sip-p.net won't add itself to the Path of the REGISTER, since it knows that the Authoritative proxy can reach ep1/ep2.isp.net directly? Thanks again /Fredrik > > ep1.isp.net (ep1.sip-p.net) > UA --NAT-- ------- ep.sip-p.net -- Authoritative proxy > / > ep2.isp.net (ep2.sip-p.net) registrar > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 11:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZtr-0001M1-Ip; Mon, 30 Oct 2006 11:22:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZtp-0001Kf-Vz for sip@ietf.org; Mon, 30 Oct 2006 11:22:10 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZth-0001t2-PD for sip@ietf.org; Mon, 30 Oct 2006 11:22:09 -0500 Received: from [192.168.2.102] ([76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9UFPYb3003928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Oct 2006 09:25:35 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4542971C.3080706@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> <4542971C.3080706@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70659CB3-73B3-4282-B3FF-E91655C2BCA1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 30 Oct 2006 10:21:49 -0600 To: IETF SIP List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] What good is SIPS:? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 does sips: do for us? It allows the end-user to ask the proxies to apply hop-by-hop cryptography and authentication, with the assurance that proxies that support the spec will honor that request. It's not a high level of security as it says nothing about and cannot detect non-compliant proxies, but it is a property that we don't have with any other SIP mechanism at this time. Many people believe this is a useful property despite its limitations. People are apparently trying to use it today, with inconsistent results. Francois' draft is intended to at least help them produce consistent results. As we think about alternatives or changes in specification, let's keep that one useful property in-mind. This leaves us with two questions, and we should try and differentiate further discussion by which question we're talking about: 1) Is it worth helping people get what they can out of SIPS: as roughly described in 3261, or is it so broken we should just suggest not bothering? 2) Do we need to do something beyond what sips:-as-per-RFC 3261 does, and if so, what properties does that something need to have? I personally suspect that there are three useful categories of "beyond": a. Fix the last-hop exception and first-hop lack-of-exception, either by eliminating it/them or more clearly codifying what we're talking about. b. Clarify the usage for non-TLS alternatives, if any. c. Provide an end-to-end alternative that is fully verifiable by the UAC (and maybe the UAS). Of course, this leaves open the question of what happens if either node is a B2BUA. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 11:27:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZxT-0008AA-MG; Mon, 30 Oct 2006 11:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeZxS-00089x-3Y for sip@ietf.org; Mon, 30 Oct 2006 11:25:54 -0500 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeZwj-0002X4-F4 for sip@ietf.org; Mon, 30 Oct 2006 11:25:54 -0500 Received: by wr-out-0506.google.com with SMTP id i5so261051wra for ; Mon, 30 Oct 2006 08:25:09 -0800 (PST) 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=fb9/cuP4BnTQq6UKHSW+1EmSB45CyQWELT3J8iG769jxX8UczvwBjuoxoQiW4tD/DmmIUWVnnvEfQPyCABmsDLZrTRrUpkeBRtzuDoSWfkC/bAFcflJkiWdKSesxt6HqIeOAE2vrkOhcxlbZhPj6PDYvcAHM5aebA55raoPHl30= Received: by 10.78.204.20 with SMTP id b20mr5132269hug; Mon, 30 Oct 2006 08:25:07 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 30 Oct 2006 08:25:07 -0800 (PST) Message-ID: <953beacc0610300825k166fff68j3753666124fa4e5a@mail.gmail.com> Date: Mon, 30 Oct 2006 08:25:07 -0800 From: "Rohan Mahy" To: EKR Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05 In-Reply-To: <20061029195222.A26F71CC22@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061029195222.A26F71CC22@delta.rtfm.com> X-Spam-Score: 0.0 (/) 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 Hi, Thanks for the editorial comments. Two answers inline. On 10/29/06, EKR wrote: > $Id: draft-ietf-sip-outbound-05-rev.txt,v 1.1 2006/10/29 19:54:58 ekr Exp $ > > S 6. > comparison purposes. A Contact header field value with an > instance-id but no reg-id is valid, but one with a reg-id but no > instance-id is not. If the registrar processes a Contact header > > When would instance-id but no reg-id happen? registering for a GRUU (has an instance-id) but not with outbound (no reg-id). > however implementations need to be preared to receive STUN > messages which cross a stream buffer boundary, and SIP and STUN > messages which share the same stream buffer. > > I don't understand what this means. If you mean that any time you > call read(1) you might get SIP and STUN messages intermixed, isn't > that a basic property of TCP? Yes, but most implementors do not have a lot of experience muxing two protocols over TCP. This turned out to be a major PIA for implementors. 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 Oct 30 11:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gea1J-0000wx-2u; Mon, 30 Oct 2006 11:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gea1H-0000wn-LR for sip@ietf.org; Mon, 30 Oct 2006 11:29:51 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gea1D-00045l-5u for sip@ietf.org; Mon, 30 Oct 2006 11:29:51 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5019F1E8C28; Mon, 30 Oct 2006 08:29:44 -0800 (PST) To: "Rohan Mahy" Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05 References: <20061029195222.A26F71CC22@delta.rtfm.com> <953beacc0610300825k166fff68j3753666124fa4e5a@mail.gmail.com> From: Eric Rescorla Date: Mon, 30 Oct 2006 08:29:44 -0800 In-Reply-To: <953beacc0610300825k166fff68j3753666124fa4e5a@mail.gmail.com> (Rohan Mahy's message of "Mon, 30 Oct 2006 08:25:07 -0800") Message-ID: <861wop937r.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 "Rohan Mahy" writes: > Hi, > > Thanks for the editorial comments. Two answers inline. > > On 10/29/06, EKR wrote: >> $Id: draft-ietf-sip-outbound-05-rev.txt,v 1.1 2006/10/29 19:54:58 ekr Exp $ >> >> S 6. >> comparison purposes. A Contact header field value with an >> instance-id but no reg-id is valid, but one with a reg-id but no >> instance-id is not. If the registrar processes a Contact header >> >> When would instance-id but no reg-id happen? > > registering for a GRUU (has an instance-id) but not with outbound (no reg-id). > >> however implementations need to be preared to receive STUN >> messages which cross a stream buffer boundary, and SIP and STUN >> messages which share the same stream buffer. >> >> I don't understand what this means. If you mean that any time you >> call read(1) you might get SIP and STUN messages intermixed, isn't >> that a basic property of TCP? > > Yes, but most implementors do not have a lot of experience muxing two > protocols over TCP. This turned out to be a major PIA for > implementors. OK. Maybe just say "As with any stream-based protocol..." -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 Mon Oct 30 11:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaLv-0007P5-RF; Mon, 30 Oct 2006 11:51:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaLu-0007OW-7D for sip@ietf.org; Mon, 30 Oct 2006 11:51:10 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeaLn-0000dK-Jg for sip@ietf.org; Mon, 30 Oct 2006 11:51:10 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 09CA3695; Mon, 30 Oct 2006 17:51:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 17:51:02 +0100 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: Outbound-05: Registrar checking all Path headers for "ob" (was: "RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneedto support outbound?") Date: Mon, 30 Oct 2006 17:50:56 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940451F44F@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F133F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Registrar checking all Path headers for "ob" (was: "RE: [Sip] Outbound issues: slides 9 and 10 - Why does every proxyneedto support outbound?") Thread-Index: Aca8jT4lem/BN+7DRkaVAjSm9Rr8igDAGg5gDy1F8pA= From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 30 Oct 2006 16:51:02.0790 (UTC) FILETIME=[9580EA60:01C6FC43] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 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 =20 Hi Rohan, Chapter 6 of outbound-05 still says that the registrar shall check ALL Path headers for the "ob" URI parameter, eventhough I think we agreed it's enough to only check the Path of the edge proxy. Or, is there a reason why all proxies in the path must insert Path with "ob"? Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 14. elokuuta 2006 13:39 > To: Rohan Mahy > Cc: IETF SIP List > Subject: RE: [Sip] Outbound issues: slides 9 and 10 - Why=20 > does every proxyneedto support outbound? >=20 >=20 > Hi Rohan,=20 >=20 > >>>Christer, please read the slides. The issue we are trying=20 > to detect=20 > >>>is described in slide 9. The UA sends through an=20 > outbound-proxy that=20 > >>>adds a Path, but does not support outbound. The registrar=20 > needs to=20 > >>>detect that. > >> > >>I am not arguing against that. I am simply commenting on=20 > 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=20 > Paths, and=20 > >>I propose a way to avoid that. > > > >Right. You should be able to compare only the first Path=20 > and the first > Via. I guess there is no reason for the other Path headers=20 > to have ;ob. >=20 > Wouldn't it be easier, and "cleaner", to say that the=20 > outbound proxy MUST always (no matter what domain it belongs=20 > to) Path with "ob"? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > 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=20 > 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=20 > 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=20 > 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=20 > hop after=20 > >>> the > >> UAC is represented in the Path list (unless the > >>> registrar recognizes that the first hop after the UAC is=20 > in the same > >> domain and doesn't need to include Path URIs with a > >>> flow token). Note that this implies that whatever the=20 > 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=20 > complete URI > >> comparison). If the first hop is not correctly > >>> represented, the registrar ignores the reg-id parameter=20 > 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=20 > 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=20 > registrations to=20 > >> all foreign domains. Inside the same domain, the=20 > first-hop proxy and >=20 > >> the registrar can still use Path to communicate with each=20 > 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 >=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=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 Oct 30 12:05:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaXK-0000XS-NZ; Mon, 30 Oct 2006 12:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaXJ-0000Uk-93 for sip@ietf.org; Mon, 30 Oct 2006 12:02:57 -0500 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 1GeaXH-0003O4-Q8 for sip@ietf.org; Mon, 30 Oct 2006 12:02:57 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2006 09:02:55 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UH2tAW019149; Mon, 30 Oct 2006 09:02:55 -0800 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 k9UH2tW4014747; Mon, 30 Oct 2006 09:02:55 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn2-927.cisco.com [10.21.115.159]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9UGoAY0017412; Mon, 30 Oct 2006 08:50:10 -0800 Message-ID: <45463041.4070801@cisco.com> Date: Mon, 30 Oct 2006 09:02:57 -0800 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 Subject: Re: [Sip] Receiver oriented signaling: (was: What good is SIPS:?) References: <1ECE0EB50388174790F9694F77522CCF0DC29639@zrc2hxm0.corp.nortel.com> <4542971C.3080706@cisco.com> <70659CB3-73B3-4282-B3FF-E91655C2BCA1@softarmor.com> In-Reply-To: <70659CB3-73B3-4282-B3FF-E91655C2BCA1@softarmor.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=4732; t=1162227775; x=1163091775; 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]=20Receiver=20oriented=20signaling=3A=20(was=3A=20What=20go od=20is=20SIPS=3A?); X=v=3Dcisco.com=3B=20h=3D35gJBFzTc70dBri5ToBKlpIftDs=3D; b=f9wNx58o+8oDLxfPP4OEPhe8cu9rEc8HIjicA2cER8Mu8IJk6D4SEl+4/WruoSb0zEx4wA9v l8K/7yFFfM4PZWU7eBYAjNXC2GjG1Nnnx8M1pMDOVsJUhf43qOHhzieV; X-Spam-Score: 0.0 (/) 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 It seems to me that SIPS has and has always had things completely wrong: it views this from the perspective of the sender who has little or no control over the path that the request is routed. About the only thing that a sender can do is say "Hey, I'd like this to happen, but I'm at your mercy." Such is the cost of transitive trust. What it seems to me is that we should not be viewing this from the standpoint of the sender, but instead of the _receiver_ who ultimately should decide whether to accept or reject a session -- and is probably in the best position to know the preferences of the possibly human callee. So instead of having a one-size-fits all approach, suppose that we just do a couple of things: 1) Allow the originator to specify whether they'd like signaling confidentiality/integrity along the path; this is NOT a demand, it is a "please". 2) Have the ability for each hop to label the level of confidentiality/integrity along the path (eg, protect=[none|tls|ipsec|docsis|...]) 3) The receiver inspects both the sender's hope, the protection afforded along the path intersected with its local policies to determine whether to accept the session or not. 4) We have also have a BCP which says nice proxies/b2bua's send messages out with as good if not better integrity/confidentialilty on the next hop This of course doesn't eliminate the possibility of lying middle proxies, but it does get rid of busy-body middle proxies who fail calls in ways that neither the sender or receiver have very good control over. I mean, ultimately we'd like to give as much control over the fate of the session to the end UA, right? This would, for example, give receivers like a phone UA the ability to determine that once it gets into its trust boundary, the necessity for TLS does not compromise its policy, and that the sender shouldn't be alarmed if it's not encrypted the entire way to the UA. Likewise, for a public PSTN gateway it might be of the mind that what the heck -- I'm going to turn around and reformat these media/signaling bits in the clear, so why should I bother consuming my resources on the previous hop? The point here is that there are a *substantial* number of scenarios that have very different needs which are trying to be rolled up into the single "S" bit of SIPS. This was a fairly reasonable thing with HTTPS since it is essentially always e2e. SIP has always had a proxy routed architecture, and is thus far more complicated... Mike, I have another idea, but I'll break that into a separate message Dean Willis wrote: > > What does sips: do for us? > > It allows the end-user to ask the proxies to apply hop-by-hop > cryptography and authentication, with the assurance that proxies that > support the spec will honor that request. > > It's not a high level of security as it says nothing about and cannot > detect non-compliant proxies, but it is a property that we don't have > with any other SIP mechanism at this time. > > Many people believe this is a useful property despite its > limitations. People are apparently trying to use it today, with > inconsistent results. Francois' draft is intended to at least help > them produce consistent results. > > As we think about alternatives or changes in specification, let's > keep that one useful property in-mind. > > This leaves us with two questions, and we should try and > differentiate further discussion by which question we're talking about: > > 1) Is it worth helping people get what they can out of SIPS: as > roughly described in 3261, or is it so broken we should just suggest > not bothering? > > > 2) Do we need to do something beyond what sips:-as-per-RFC 3261 does, > and if so, what properties does that something need to have? I > personally suspect that there are three useful categories of "beyond": > > a. Fix the last-hop exception and first-hop lack-of-exception, > either by eliminating it/them or more clearly codifying what we're > talking about. > > b. Clarify the usage for non-TLS alternatives, if any. > > c. Provide an end-to-end alternative that is fully verifiable by > the UAC (and maybe the UAS). Of course, this leaves open the question > of what happens if either node is a B2BUA. > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 30 12:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaYx-0003Q6-6F; Mon, 30 Oct 2006 12:04:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaYw-0003Q1-BT for sip@ietf.org; Mon, 30 Oct 2006 12:04:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeaYt-0003hb-0W for sip@ietf.org; Mon, 30 Oct 2006 12:04:38 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BA6BB78F; Mon, 30 Oct 2006 18:02:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 18:02:59 +0100 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: Outbound-05: Proxy STUN keepalive support flag (was: "RE: [Sip] Outbound Issues: slides 3 and 4") Date: Mon, 30 Oct 2006 18:02:56 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB5940451F4BC@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Proxy STUN keepalive support flag (was: "RE: [Sip] Outbound Issues: slides 3 and 4") Thread-Index: Aca/uncLg6z7YObNTI6HgI4j5sk1Yw8ibO8A From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 30 Oct 2006 17:02:59.0782 (UTC) FILETIME=[40DD3660:01C6FC45] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 =20 Hi, One of the issues we discussed earlier was to define a flag (URI parameter, or something else) so that a proxy can indicate the support of STUN keepalive. The proxy would insert this flag in the Path header, and the Path header (or the Service-Route, if Jonathan's route-construct draft is adopted) would then be returned to the user. (The advantage of this is that the UA would not have to send OPTIONS, or send let's-try-and-see STUN requests, to find out whether the edge proxy supports it or not) Regards, Christer=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 Oct 30 12:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geafq-0006Ye-H2; Mon, 30 Oct 2006 12:11:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geafp-0006YS-Hl for sip@ietf.org; Mon, 30 Oct 2006 12:11:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geafn-00058q-83 for sip@ietf.org; Mon, 30 Oct 2006 12:11:45 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2006 09:11:42 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9UHBgZj031807 for ; Mon, 30 Oct 2006 09:11:42 -0800 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 k9UHBgAo008168 for ; Mon, 30 Oct 2006 09:11:42 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn2-927.cisco.com [10.21.115.159]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9UGwvib017609 for ; Mon, 30 Oct 2006 08:58:57 -0800 Message-ID: <45463250.7070103@cisco.com> Date: Mon, 30 Oct 2006 09:11:44 -0800 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: IETF SIP List 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=1159; t=1162228302; x=1163092302; 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:SIPS=3A=20why=20not=20S/MIME=20instead?; X=v=3Dcisco.com=3B=20h=3DQEo/pdZzHptNF5xooPgDaqxLsww=3D; b=nRqBMdaVRM0WWFGP2la6FZAxjTR/OXcltev58JV05mOU7ap0Avua+tcCdD4YJ5MoMHltsPeY BfSVr4Hyvf4T6QBK3IW2K7uK2NMczGIzTuEG0ojA0yU1OYryqruQWxKq; X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] SIPS: why not S/MIME instead? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As an alternative of my previous proposal, there seems to be quite a bit of unhappiness of the general bogosity of the last hop (UAS) exception of SIPS. If we remove that restriction, I guess I have to ask the question if you want integrity/confidentiality along the path where you ultimately have no real control over the transport chosen by middle proxies -- why don't you just get/learn the cert of the intended party and use S/MIME which actually give you the security properties that you're most likely hoping for with SIPS? It seems to me that either S/MIME directly to the UAS or to some trusted upstream agent for the UAS would be a *lot* better than hoping that you'll get TLS the whole path, not least of which is that it eliminates the lying middle proxy problem. And if you're going to insist on TLS, you need certs in all of those things anyway, so why not just ignore the TLS aspect and use S/MIME? Which isn't to say that TLS is not useful, but SIPS is trying to approximate what S/MIME gets you, so it's not clear why you shouldn't we shouldn't be promoting it instead of the obvious hack that SIPS is. 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 Oct 30 12:18:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeakQ-0001Or-3M; Mon, 30 Oct 2006 12:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeakO-0001Oi-31 for sip@ietf.org; Mon, 30 Oct 2006 12:16:28 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeakK-0005yi-GG for sip@ietf.org; Mon, 30 Oct 2006 12:16:28 -0500 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 k9UHGCs12714; Mon, 30 Oct 2006 12:16:12 -0500 (EST) 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] New I-D on UA loose routing Date: Mon, 30 Oct 2006 11:16:07 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371112D04EF@zrc2hxm2.corp.nortel.com> In-Reply-To: <953beacc0610300721x513a8296gf70df33d2eca2afb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New I-D on UA loose routing Thread-Index: Acb8OIkpW6MZ9p6EQKq0+rs2vNgxmQADlJpA From: "Brian Stucker" To: "Rohan Mahy" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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 Ok, so revising my earlier response, what about embedding a SIP header called "UA-Opaque" in the URI so that we can (I think) continue to use baseline UA behavior. Regards, Brian > -----Original Message----- > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 > Sent: Monday, October 30, 2006 9:22 AM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] New I-D on UA loose routing >=20 > Hi, >=20 > First I'd like to propose a concrete counter proposal. Dean=20 > would call this an additional "band-aid" but I feel like the=20 > patient has painfully managed to recover pretty well from 2nd=20 > degree burns over 60% of the body and now just has a=20 > persistent paper cut. >=20 > We define a new URI parameter called 'ua-opaque'. When an=20 > authoritative proxy receives a request with this parameter in=20 > the request URI (in an AOR or a GRUU), it copies the value of=20 > this parameter into any URI it retargets to. This=20 > functionality is mandatory for URIs which are GRUU. This=20 > parameter effectively replaces the 'grid' parameter by=20 > providing a simple superset of the functionality. >=20 > I believe that this approach has significantly better=20 > backwards compatility and maturity than the UA loose-route=20 > approach. Below I will list the technical problems I see with=20 > the UA loose route approach. >=20 > 1) Outbound. the current outbound draft has language about=20 > what the first edge proxy needs to do. One of the ways to=20 > tell if the first proxy did its job is to check the first=20 > element in the Path vector for the 'ob' parameter. I don't=20 > believe this would work anymore. Maybe I am not smart=20 > enough, but I can't think of a way to make detection that=20 > outbound will work in a UA loose-route environment, short of=20 > a first-hop Proxy-Require, which a number of folks where=20 > adamantly against. >=20 > 2) Forking / HERFP. There are some UAs which reject requests=20 > to them with Route headers left with a 400 and some with a=20 > 403. To be safe, a proxy will need to forward in the=20 > traditional manner to non-loose-route UAs, or risk=20 > exacerbating HERFP. A proxy forking to both UA loose-route=20 > and non-UA loose UAs therefore needs to keep track of both=20 > and effectively run two separate code paths for different=20 > branches for the same target set. >=20 > 3) Marid-style assumptions. Like the problem with outbound,=20 > a proxy that wants to check that requests are either for its=20 > domain or from its domain and that it is receiving requests=20 > for its domain directly (not through an intervening proxy)=20 > may have a harder time figuring out if it is the first proxy. >=20 > thanks, > -rohan >=20 >=20 > On 10/26/06, Jonathan Rosenberg wrote: > > You are equating processing a Route header, with being a proxy.=20 > > Nothing in RFC 3261 says that if you process a Route=20 > header, you are a proxy. > > Indeed, RFC 3261 is silent on the applicability of Route=20 > headers to UA. > > Certainly I agree we don't want to require a UA to do thigns like=20 > > mutual TLS. > > > > Indeed, I would like to understand what concrete problems you see.=20 > > Your note points out that there could be other solutions, and then=20 > > complains that this is making things confusing. Yes, there could be=20 > > other solutions - I look forward to your draft. I don't=20 > think it makes=20 > > things more confusing. > > > > I think this mechanism is quite elegant in that extends the idea of=20 > > loose routing to UA, and is arguably what we should have=20 > done in SIP=20 > > in the first place. > > > > -Jonathan R. > > > > > > > > > > > > Rohan Mahy wrote: > > > > > Hi, > > > > > > I have read this draft and I think it is a terrible idea=20 > in SIP/2.0=20 > > > to send a UA an incoming request with a Route header. If we were=20 > > > working on SIP/2.1 or SIP/3.0, I think this approach would be a=20 > > > fruitful idea to consider as baseline behavior, but I=20 > think this is=20 > > > too major of a change from the current spec and state of=20 > implementation. > > > > > > Lets analyze the requirements described in the document. =20 > The unkown=20 > > > gruu, limited-use gruu, subaddressing, and service invocation=20 > > > requirements can all be met just by restoring the grid=20 > parameter to=20 > > > its rightful place in GRUU. The emergency services=20 > requirement is a=20 > > > tautology; if a proxy wants to rewrite the Request-URI=20 > from an SOS=20 > > > URN, don't do that, insert a loose-route instead; no additional=20 > > > mechanism or specification is necessary. The freephone=20 > requirement=20 > > > deals with mixed SIP and PSTN networks, where the existing=20 > > > History-Info (or dare I say Diversion) mechanism is perfectly=20 > > > adequate and more likely to be implemented in this=20 > environment. The=20 > > > alias requirement can be addresses in a variety of ways including=20 > > > configuration, or simply restoring the To header to=20 > usefulness. My=20 > > > conclusion is that this mechanism does not solve any=20 > requirements we=20 > > > are not already addressing. (If we were starting from=20 > scratch, we=20 > > > might do things differently). > > > > > > As for the implications of handling loose-routing on the UA, I do=20 > > > not believe the expected behavior is easily containable. The only=20 > > > entities that should receive requests with additional=20 > Route headers=20 > > > are proxy servers. Embedding a proxy server in/on a UA then=20 > > > requires the UA to implement TLS, strict route fix ups, loop=20 > > > detection, and a host of other things. I don't think we=20 > want to go=20 > > > there. The alternative is for us to break the rules and define a=20 > > > "sort of a proxy" role. I expect picking apart what parts of=20 > > > RFC3261 need to be implemented as a proxy would be a=20 > nightmare. I=20 > > > can also imagine the impact on the outbound draft if each=20 > outbound=20 > > > UA needs to route through an embeded edge proxy. How=20 > will the first=20 > > > "real" edge proxy decide if outbound processing has been=20 > done correctly? > > > > > > The concept of logical roles such as proxy, registrar, identity=20 > > > server, etc. is already confusing to many implementors.=20 > If we start=20 > > > redefining or breaking the rules which describe existing roles, I=20 > > > believe we are going to have a real mess on our hands. > > > > > > thanks, > > > -rohan > > > > > > > > > > > > On 10/13/06, Jonathan Rosenberg wrote: > > > > > >> I've submitted a new I-D which describes this concept of=20 > UA loose=20 > > >> routing that we've been discussing on the list. This fell out of=20 > > >> the GRUU discussions as an alternative solution for grid. As the=20 > > >> draft explains, the mechanism also solves many other=20 > problems, like=20 > > >> sub-addressing, limited use adresses, 8xx number usage,=20 > and is even=20 > > >> required for proper 911/emergency services operation with ecrit. > > >> > > >> Until the draft appears in the archives, you can pick it up at: > > >>=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00 > > >> .txt > > >> > > >> Thanks, > > >> Jonathan R. > > >> -- > > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >> Cisco Fellow =20 > Parsippany, NJ 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 > > >> > > > > > > > -- > > 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=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 Oct 30 12:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeanM-0004QU-NR; Mon, 30 Oct 2006 12:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeanJ-0004QC-4O for sip@ietf.org; Mon, 30 Oct 2006 12:19:29 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeanA-0006il-I2 for sip@ietf.org; Mon, 30 Oct 2006 12:19:29 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9UHJJYZ106352 for ; Mon, 30 Oct 2006 17:19:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9UHMAiC2891924 for ; Mon, 30 Oct 2006 18:22:10 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9UHJJ05021857 for ; Mon, 30 Oct 2006 18:19:19 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9UHJJvY021854; Mon, 30 Oct 2006 18:19:19 +0100 In-Reply-To: <70659CB3-73B3-4282-B3FF-E91655C2BCA1@softarmor.com> To: Dean Willis MIME-Version: 1.0 Subject: Re: [Sip] What good is SIPS:? X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Mon, 30 Oct 2006 19:22:06 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 30/10/2006 19:22:10, Serialize complete at 30/10/2006 19:22:10 X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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="===============0135841057==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0135841057== Content-Type: multipart/alternative; boundary="=_alternative 005F2BB6C2257217_=" This is a multipart message in MIME format. --=_alternative 005F2BB6C2257217_= Content-Type: text/plain; charset="US-ASCII" In a closed system there is no need for SIPS since the system knows if it is secure or not. I an open system we know nothing about intermediaries so SIPS only gives the feeling of security which to me seems worse then knowing that the connection is not secure at all. If we can achieve 2.c then we can use SIPS for that until then SIPS seems more confusing then helping. --Avshalom Dean Willis 30/10/2006 18:21 To IETF SIP List cc Subject [Sip] What good is SIPS:? What does sips: do for us? It allows the end-user to ask the proxies to apply hop-by-hop cryptography and authentication, with the assurance that proxies that support the spec will honor that request. It's not a high level of security as it says nothing about and cannot detect non-compliant proxies, but it is a property that we don't have with any other SIP mechanism at this time. Many people believe this is a useful property despite its limitations. People are apparently trying to use it today, with inconsistent results. Francois' draft is intended to at least help them produce consistent results. As we think about alternatives or changes in specification, let's keep that one useful property in-mind. This leaves us with two questions, and we should try and differentiate further discussion by which question we're talking about: 1) Is it worth helping people get what they can out of SIPS: as roughly described in 3261, or is it so broken we should just suggest not bothering? 2) Do we need to do something beyond what sips:-as-per-RFC 3261 does, and if so, what properties does that something need to have? I personally suspect that there are three useful categories of "beyond": a. Fix the last-hop exception and first-hop lack-of-exception, either by eliminating it/them or more clearly codifying what we're talking about. b. Clarify the usage for non-TLS alternatives, if any. c. Provide an end-to-end alternative that is fully verifiable by the UAC (and maybe the UAS). Of course, this leaves open the question of what happens if either node is a B2BUA. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 005F2BB6C2257217_= Content-Type: text/html; charset="US-ASCII"
In a closed system there is no need for SIPS since the system knows
if it is secure or not.

I an open system we know nothing about intermediaries so SIPS only
gives the feeling of security which to me seems worse then knowing that
the connection is not secure at all.

If we can achieve 2.c then we can use SIPS for that until then SIPS
seems more confusing then helping.

--Avshalom


Dean Willis <dean.willis@softarmor.com>

30/10/2006 18:21

To
IETF SIP List <sip@ietf.org>
cc
Subject
[Sip] What good is SIPS:?






What does sips: do for us?

It allows the end-user to ask the proxies to apply hop-by-hop  
cryptography and authentication, with the assurance that proxies that  
support the spec will honor that request.

It's not a high level of security as it says nothing about and cannot  
detect non-compliant proxies, but it is a property that we don't have  
with any other SIP mechanism at this time.

Many people believe this is a useful property despite its  
limitations. People are apparently trying to use it today, with  
inconsistent results. Francois' draft is intended to at least help  
them produce consistent results.

As we think about alternatives or changes in specification, let's  
keep that one useful property in-mind.

This leaves us with two questions, and we should try and  
differentiate further discussion by which question we're talking about:

1) Is it worth helping people get what they can out of SIPS: as  
roughly described in 3261, or is it so broken we should just suggest  
not bothering?


2) Do we need to do something beyond what sips:-as-per-RFC 3261 does,  
and if so, what properties does that something need to have? I  
personally suspect that there are three useful categories of "beyond":

                a. Fix the last-hop exception and first-hop lack-of-exception,  
either by eliminating it/them or more clearly codifying what we're  
talking about.

                b. Clarify the usage for non-TLS alternatives, if any.

                c. Provide an end-to-end alternative that is fully verifiable by the  
UAC (and maybe the UAS). Of course, this leaves open the question of  
what happens if either node is a B2BUA.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 005F2BB6C2257217_=-- --===============0135841057== 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 --===============0135841057==-- From sip-bounces@ietf.org Mon Oct 30 12:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geb2Q-0005zf-P0; Mon, 30 Oct 2006 12:35:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geb2P-0005z2-0w for sip@ietf.org; Mon, 30 Oct 2006 12:35:05 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geb2G-0002kT-A2 for sip@ietf.org; Mon, 30 Oct 2006 12:35:05 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 898691F3; Mon, 30 Oct 2006 18:34:53 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 18:34:53 +0100 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 route construct specification Date: Mon, 30 Oct 2006 18:34:52 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB59404548FE1@esealmw113.eemea.ericsson.se> In-Reply-To: <4535367D.6030707@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated route construct specification Thread-Index: AcbyW9XxsrUWNBP+T6+5lsVI441LvgJ6v9Zw From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 30 Oct 2006 17:34:53.0598 (UTC) FILETIME=[B5965BE0:01C6FC49] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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, Thank you for putting this document together! Some initial comments and questions. My FIRST comment/question is: do we really need the "p2sr" flag? Isn't it enough that, if the UA includes the "sr" flag, that the registrar simply generates the Service-Route based on the Path and return it to the UA? My SECOND comment/question is on the "table" on page 9. In rows 2, 3 and 5 it is indicated that the new SR procedures are used, ie the Service-Route should override the outbound proxy in the UA. Now, in an IMS scenario P1 could be a P-CSCF, and if it doesn't insert the "p2sr" it would not receive the initial requests. Or, have I missunderstood? My THIRD comment/question is on the statement in chapter 2.3. The text says: "RFC 3261 is also clear that the resulting route set applies to mid-dialog requests. It implies (though does not explicitly say) that the resulting route set overrides any default outbound proxies (which represent a pre-loaded route set)." I don't think this is "clear" at all, and from my interop experience the does-the-outbound-proxy-apply-to-mid-dialog-requests question comes up quite often. And, just a couple of weeks ago I was informed about a Cisco phone sending BYE to the outbound proxy, instead of using the route set, so... ;) My FOURTH comment/question is on the statement in chapter 6.1, saying that the Service-Route is recomputed for each registration. I think it would be good to mention that in that sense the Service-Route is DIFFERENT from Record-Route/Route, which is not recomputed (e.g. using re-INVITE/UPDATE) once it has been created. Only the remote/local target can be changed. Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 17. lokakuuta 2006 23:01 > To: IETF SIP List > Subject: [Sip] Updated route construct specification >=20 > I've updated this document. It is (once again) almost=20 > completely rewritten. Until it appears in the archives, you=20 > can pick it up at: >=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-route-constr > uct-02.txt >=20 > Basically, it proposes to turn Service-Route into the inverse=20 > of Path, so that Service-Route/Path work more like=20 > record-routing. This is now specified in a way which is=20 > backwards compatible with IMS, which was an issue for the=20 > previous spec. I believe this makes service-route usable for=20 > the internet at large, and it is a key part of solving the=20 > sip-outbound mid-dialog failover problem. Its also WAY=20 > simpler than previous versions. The whole bit in there about=20 > redirections overriding route sets is now folded into the=20 > more general UA loose routing document I also published. >=20 > Just to get some controversy thrown in there, the draft also=20 > specifies as part of its behavior that a UA register only a=20 > single contact at a time, and only that contact get reflected=20 > in the REGISTER response. >=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=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 Oct 30 12:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geb8V-0006aW-KO; Mon, 30 Oct 2006 12:41:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geb8U-0006aD-9o; Mon, 30 Oct 2006 12:41:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geb8M-0004Bz-3u; Mon, 30 Oct 2006 12:41:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2006 09:41:14 -0800 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 k9UHfDop022047; Mon, 30 Oct 2006 12:41:13 -0500 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 k9UHfDDM019351; Mon, 30 Oct 2006 12:41:13 -0500 (EST) 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); Mon, 30 Oct 2006 12:41:13 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.153]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 12:41:12 -0500 Message-Id: <4.3.2.7.2.20061030113259.02542550@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Oct 2006 11:41:11 -0600 To: "Thomson, Martin" , "Jeroen van Bemmel" , From: "James M. Polk" Subject: RE: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-05.txt In-Reply-To: References: <005601c6f412$442d0e70$0601a8c0@BEMBUSTER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Oct 2006 17:41:12.0508 (UTC) FILETIME=[976F6FC0:01C6FC4A] DKIM-Signature: a=rsa-sha1; q=dns; l=7351; t=1162230073; x=1163094073; c=relaxed/simple; s=rtpdkim1001; 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]=20Re=3A=20[Sip]=0A=20=20I-DACTION=3Adraft-ietf-sip-loc ation-conveyance-05.txt=20 |To:=22Thomson, =20Martin=22=20, =0A=20=20=20=20=20 =20=20=20=22Jeroen=20van=20Bemmel=22=20, =20; X=v=3Dcisco.com=3B=20h=3D/W0vZ7rtFATc21r4LZ3KfmHJS3M=3D; b=hBmUV4hBJpyYZ8eIKVbsdDKRJi1tjU9DMKITCpRprpHY9VAfrMXS+PgxYqM/bRnDGQPZHEPj 5L2Fx4q2BlS6xnkaLoJ685aQFWPf02EJ+BG5c2uyjaEtfOvYuBAVpbml; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: geopriv@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 06:54 PM 10/22/2006 -0500, Thomson, Martin wrote: >Content-Type: text/plain; > charset="utf-8" >Content-class: urn:content-classes:message > >The extra PIDF-LO tag is the only feature of the draft that I have a >problem with. Martin I'm not sure I understand which extra tag you are referring to > This seems like a case where the letter of the law is taken over the > spirit of the law. > >I agree with Jeroen in that a SIP proxy should not have to change its >behaviour. What would be more sensible is to acknowledge that a SIP >message with an unencrypted body can be seen by all proxies. I think this is obvious by this in the draft Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Geolocation Rr ar o - - o o o - Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Geolocation Rr ar o o o o o o - Table 1: Summary of the Geolocation Header where it clearly states the proxy can read the message body. >By including a PIDF-LO in this way, you _implicitly_ give proxies >permission to forward it. You don't need special tags for that. That >covers the large number of proxies that don't care, that haven't been >upgraded, or that will not be upgraded. > >I also don't like the idea that this updates RFC 4119 without saying it. My co-author snuck in a RFC4119 update in -04, which was removed in -05. Can you tell me where else you think this ID officially (or how you read if should be officially) updates 4119? Currently, I think -05 of this doc only updates RFC3326 with a new Reason protocol. There has been mention of taking the Location Error Code Registry ID and incorporating it into this Conveyance ID, which will add to this update of 3326. >~ >Martin > >* My understanding is that the "routing-query-allowed" tag only applies to >by-value; a by-reference URI can be forwarded without concerns**. > >** There are now cases where this may no longer be true... FFS. > > > -----Original Message----- > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Friday, 20 October 2006 4:38 PM > > To: sip@ietf.org > > Cc: geopriv@ietf.org > > Subject: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance- > > 05.txt > > > > "The entities receiving location MUST obey the privacy and security rules > > in > > the PIDF-LO as described in RFC4119, regarding retransmission and > > retention." > > > > Does this mean that a SIP proxy receiving a request with a Geolocation > > must > > first inspect the location object before forwarding? For > > location-by-reference, this may introduce an unacceptable delay, > > especially > > when the proxy does not do anything with the location information itself. > > > > Proxies that don't understand Geolocation will forward as usual, possibly > > violating the forwarding policy. You may want to spend some words on this. > > For proxies that do understand, you could consider inserting a flag in a > > SIP > > Geolocation header for the by-reference case, such that a dereference is > > not > > needed to obtain the policy > > > > Regards, > > Jeroen > > > > Internet-Drafts@ietf.org wrote: > > >> 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-05.txt > > >> Pages : 26 > > >> Date : 2006-10-19 > > >> > > >> 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- > > 05.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-05.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-05.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 > > > > > > _______________________________________________ > > 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. >------------------------------------------------------------------------------------------------ >[mf_______________________________________________ >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 Mon Oct 30 13:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebPP-0000tl-WF; Mon, 30 Oct 2006 12:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebOx-0000jO-Kn for sip@ietf.org; Mon, 30 Oct 2006 12:58:23 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebDy-00053X-0z for sip@ietf.org; Mon, 30 Oct 2006 12:47:04 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2006 09:47:02 -0800 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 k9UHl1x3025522 for ; Mon, 30 Oct 2006 12:47:01 -0500 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 k9UHl1DQ021452 for ; Mon, 30 Oct 2006 12:47:01 -0500 (EST) 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, 30 Oct 2006 12:47:01 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.153]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 12:47:01 -0500 Message-Id: <4.3.2.7.2.20061030102733.034f7600@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Oct 2006 11:47:00 -0600 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Oct 2006 17:47:01.0309 (UTC) FILETIME=[67563ED0:01C6FC4B] DKIM-Signature: a=rsa-sha1; q=dns; l=1120; t=1162230421; x=1163094421; c=relaxed/simple; s=rtpdkim1001; 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:-05=20of=20SIP=20Location=20Conveyance=20submitted |To:sip@ietf.org; X=v=3Dcisco.com=3B=20h=3D495Qf9RkVs4NeD2odW2Y+4Eq8OI=3D; b=SMYOMoRmap2fAU0aui2/kyt0H/lze2ws3gksBuy4GtbExdP6VD8r70dyzdZGHUVdhCZgOWLU Go1oK8ti3k2YWpKTgCI0Pymv8T0tdiNM47mkf2/AFfa+pkHsTPHRyh/S; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Sip] -05 of SIP Location Conveyance submitted X-BeenThere: sip@ietf.org X-Mailman-Version: 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 WG We've submitted the -05 version of SIP Location Conveyance for WG review. The URL of the ID is here: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-05.txt -05 has the following changes: - altered the meaning of use of OPTIONS to not be for retrieving the location of a UAS, but for cases in which location is a required element of information by a SIP entity. - added a comment/warning for usage of location-by-reference to a model in which a domain's LIS be reachable if location is deployed in this fashion (Section 4.3) - added a Informative reference to a new ID that is an IANA registry of location specific error codes to be used in, for example, a Reason header, to give more granular reasons why a 424 (Bad Location Information) was sent. One large remaining open issue is whether or not to allow Location-by-reference URI at all. There is a Issue BoF next Wed afternoon on this topic. Comments on the list would be appreciated beforehand. Comments would be appreciated Thanks James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 13:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebTR-0002Xc-0U; Mon, 30 Oct 2006 13:03:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebTK-0002Wz-Vw; Mon, 30 Oct 2006 13:02:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebTH-0001LN-LP; Mon, 30 Oct 2006 13:02:54 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 10:02:50 -0800 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 k9UI2oNl031935; Mon, 30 Oct 2006 10:02:50 -0800 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 k9UI1xbh027142; Mon, 30 Oct 2006 10:02:50 -0800 (PST) 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, 30 Oct 2006 13:02:36 -0500 Received: from jmpolk-wxp.cisco.com ([10.89.20.153]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 13:02:36 -0500 Message-Id: <4.3.2.7.2.20061030120032.03456258@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Oct 2006 12:02:34 -0600 To: "Jeroen van Bemmel" , From: "James M. Polk" Subject: Re: [Geopriv] Re: [Sip] I-D ACTION:draft-ietf-sip-location-conveyance-05.txt In-Reply-To: <004b01c6f411$2b1585d0$0601a8c0@BEMBUSTER> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 30 Oct 2006 18:02:36.0257 (UTC) FILETIME=[949BFD10:01C6FC4D] DKIM-Signature: a=rsa-sha1; q=dns; l=813; t=1162231370; x=1163095370; c=relaxed/simple; s=sjdkim5002; 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]=20Re=3A=20[Sip]=20I-D=0A=20=20ACTION=3Adraft-ietf-sip- location-conveyance-05.txt=20; X=v=3Dcisco.com=3B=20h=3DTUiHPWJaB4V5OVN9owRpEX5XAvs=3D; b=dnY0mAu2oUUDicAs25Zd2kjLj8J2N5H8wDdWhbPV6u987cMmXdV7HxFy8Nhp2B5aUejbgD5H DWiXwMVJWHB/NJ9llRPMf5lHfXpZ/JpXwksvBs2jDnY/e+/Vn8XjPzee; Authentication-Results: sj-dkim-5.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: geopriv@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 08:29 AM 10/20/2006 +0200, Jeroen van Bemmel wrote: >Geolocation = "Geolocation" HCOLON (locationValue *(COMMA > locationValue))locationValue = LAQUOT > locationURI RAQUOT *(SEMI generic-param)locationURI = sip-URI / > sips-URI / pres-URI / cid-URI > / absoluteURI >cidURI = "cid:" content-id >content-id = addr-spec ; URL encoding of RFC3261 addr-spec >Second comment: section 3.5 still contains the phrase "Appearance of the >option tag in the Require header is a request for location to be conveyed." I missed this when taking out the whole idea of using OPTIONS to learn the UAS's location (sorry!). This will be removed. >Such semantics are not common for Require > >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 Mon Oct 30 13:25:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gebma-00022z-B4; Mon, 30 Oct 2006 13:22:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GebmZ-00022u-NE for sip@ietf.org; Mon, 30 Oct 2006 13:22:47 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GebmS-0005XU-Ou for sip@ietf.org; Mon, 30 Oct 2006 13:22:47 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gebmf-0006yK-D5; Mon, 30 Oct 2006 12:22:53 -0600 From: "Brian Rosen" To: "'Elwell, John'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 13:22:36 -0500 Message-ID: <02f501c6fc50$621319c0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> Thread-Index: Acb7/wvPhKOiqNqmQFKYt6HsHqH6AwANDxEg 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: 3971661e40967acfc35f708dd5f33760 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 Okay, let's tackle some of these issues. I think in order to be useful: sips: means yes you must carry TLS through B2BUAs and anything else that could create an unsecure link sips: means fail if you terminate on a gateway that interworks to a non TLS supported protocol, and the gateway must carry TLS through a protocol that supports TLS. Nothing else makes sense to me. For B2BUAs and SBCs and other things, I think there is a simple test: if the ciphersuite included encryption, is the signaling encrypted end to end? For gateways, I think talking about interworking to non TLS secured protocols is not what I want the sips success to mean. It's not a secure TLS hop by hop end to end. This is especially true if the gateway is to the PSTN. It does mean that a gateway that interworked to, say H.323 could succeed with sips if it was possible to determine that the H.323 signaling was TLS protected all the way. Brian > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, October 30, 2006 3:36 AM > To: 'IETF SIP List' > Subject: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) > > Some of the discussion on the long thread on "TLS meaning" has led me to > seek opinions on what does indeed control the lock icon, since we seem to > have consensus that a successful SIPS request is not grounds for showing > the > lock icon. > > The user surely will expect media to be secured end-to-end. By end-to-end, > I > mean at least as far as the domain the user believes he/she is in > communication with. So there has to be some cryptographic assurance that > the > entity with which the UA agrees keys for media security has the > credentials > of the entity indicated by caller or connected party identity > (From+Identity > or possibly PAI). This is probably a sufficient condition if key agreement > is carried out using D-H. If the key is transported, then an additional > condition is that the key is end-to-end encrypted, which for SDescriptions > means encrypted using S/MIME. > > But what about the presence of B2BUAs, SBCs, etc. that do not have the > credentials of the end user but nevertheless terminate media security? > Here > the UA could find that it does media negotiation with service-provider.net > rather than with the end user (user@example.com). It seems the lock item > should not be displayed in this situation. Or maybe the user could be > consulted whether he/she accepts the certificate of the intermediary even > though it fails to identify the remote user. > > Another situation is where a user is trying to contact > +123456789@example.com but gets back a From/Identity indicating > +123456789@service-provider.net and media is secured as far as > service-provider.net. Does this constitute grounds for displaying the > icon? > > John > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: 29 October 2006 21:26 > > To: 'EKR'; 'David R Oran' > > Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > > 'Francois Audet'; 'Dean Willis' > > Subject: RE: [Sip] RE: TLS meaning > > > > > > > > > -----Original Message----- > > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > Sent: Saturday, October 28, 2006 9:34 AM > > > >From a security perspective, SIPS has two important properties: > > > > > > 1. It says to the client "you MUST talk to me over SSL". > > > > I hope it doesn't say that. I thought we had to use TLS. ;) > > > > > > > 2. It says to the proxies "I expect you to make the outgoing > > > connection with TLS". > > > > > > As Samir has observed, the second property can be provided with some > > > indicator in the SIP header. However, the first can only be provided > > > by putting the indicator in the reference which you hand > > around (i.e., > > > the SIP URI). This isn't to say it necessarily has to be a new URI > > > scheme--though it did in HTTP because HTTP doesn't have > > > parameters--but it's not clear to me that moving it to parameters > > > would really help. > > > > I think the part some of us are worried about is it will inherit the > > perception of https: namely that the entire path from the > > caller to the > > answerer is secure. Just because an IETF doc says it's not > > the same, and > > says it's not a lock icon, will not overcome the perception. > > Even though an > > https connection is only secure to the TLS terminator (the > > server or an > > offloader), and the back-end from there is not, the > > assumption is the owner > > of the terminator takes on the responsibility from there (if > > there is any > > responsibility). And the terminator owner wanted to secure > > it between the > > browser and the terminator, and they got that. > > > > But SIP is neither HTTP nor SMTP. The sips uri may end at a > > pstn gateway, > > or an h323 IWF, or whatever. It may become sip later, as > > well. The owner > > of the TLS terminator does not necessarily equal the owner of > > the final UAS, > > nor the owner of the answerer. How can the owner of the > > terminator have any > > responsibility for something that may happen somewhere else, > > unbeknownst to > > him? How/why would someone who types in a sips uri for their > > request not > > think it's like https? > > > > In some ways the perception problem is exacerbated by the uri > > being the sips > > scheme. If it were a require/proxy-require instead, it would > > help alleviate > > that perception problem, IMO. But then you're left with trying such a > > request without the foreknowledge of success probability that a > > business-card sips address would give you. > > > > -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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 13:49:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecAp-0002OB-S4; Mon, 30 Oct 2006 13:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecAo-0002M6-4O for sip@ietf.org; Mon, 30 Oct 2006 13:47:50 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GecAk-0003GB-RB for sip@ietf.org; Mon, 30 Oct 2006 13:47:50 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GecAj-00072C-2d for sip@ietf.org; Mon, 30 Oct 2006 13:47:46 -0500 Message-Id: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 30 Oct 2006 13:45:53 -0500 To: "'IETF SIP List'" From: "Joel M. Halpern" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> References: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112032ec25108862fb4a0e4f8b9ab4889364082d9e9c682ec76f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 removed most of the attribution below because the question of who said it, or what exactly he said, is not my point at the moment. At 01:22 PM 10/30/2006, Someone wrote: >Okay, let's tackle some of these issues. > >I think in order to be useful: >sips: means .... > >Nothing else makes sense to me. Having had several off line discussions with people who know their stuff very well about this SIPS issue, what has become very clear to me is that different participants have very different mental models of the relative roles and responsibilities of the proxies and the initiating / terminating UAs in the SIP exchanges. And different understandings of what the expressed user desire is when they say "sips:". This then results in people saying "nothing else makes sense to me." In fact, I still am having trouble understanding some of the points of view, because of this model conflict. (And I will readily admit that my mental model of what's going on may be wrong. But I can't seem to get to another one.) We then end up talking past each other. Yours, Joel M. Halpern PS: I am deliberately being a bit vague on the model mismatches for two reasons. Firstly, I think there are many more mismatches than just the ones between me and my correspondents. Secondly, I really don't want to mischaracterise other people's arguments. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 14:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecY4-0007Mp-0r; Mon, 30 Oct 2006 14:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecY1-0007Mi-07 for sip@ietf.org; Mon, 30 Oct 2006 14:11:49 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GecXx-0005iJ-DH for sip@ietf.org; Mon, 30 Oct 2006 14:11:48 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 11:11:44 -0800 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 k9UJBiTi023394; Mon, 30 Oct 2006 11:11:44 -0800 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 k9UJBabX014397; Mon, 30 Oct 2006 11:11:44 -0800 (PST) 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); Mon, 30 Oct 2006 14:11:30 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:11:29 -0500 Message-ID: <45464E61.6030305@cisco.com> Date: Mon, 30 Oct 2006 14:11:29 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 19:11:29.0590 (UTC) FILETIME=[34448D60:01C6FC57] DKIM-Signature: a=rsa-sha1; q=dns; l=6678; t=1162235504; x=1163099504; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3Dr0kv6ZvsYOsda2FiXktGBPaN+fc=3D; b=o74AkfRDKEclmb8YthomjKVqGlftqaAjKZwrUOHN2vfeyr6dYp1raWNsBeHlhw6XzCdXN11t hjukHUTROwTy4kcsheV3aq7RG2q83UM8lm3w+Eq3D6LvYAs/KudNSnBZ; 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: 87a3f533bb300b99e2a18357f3c1563d 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 support John here. As stupid as it might seem, I think this little thing is likely to be very important. And figuring out what it takes to have it is a way at getting to underlying requirements for security in the protocol. Perhaps there are also other requirements for security, but at least this would provide one source. So far I have heard that having a SIPS connection doesn't imply that one can show this lock icon. What isn't yet clear to me is if that means that SIPS is a necessary but insufficient condition, or if SIPS is in fact not even helpful for providing it. I suspect it isn't even helpful. If not, then what *is* driving the requirements for SIPS? I think I would also extend John's proposal a bit. I think there *may* need to be different levels of security, where the lock icon corresponds to one of them. But this is a slippery slope, because if there are too many they become confusing to users. But too few of the wrong ones may not be useful in practice. For instance, it may be that there is a need for "PSTN quality" security. (I imagine that *ought* to be the same as "none", but in practice I think the PSTN level security is better than basic unsecured-sip-over-internet security, so knowing you had this when connected to the PSTN could be helpful.) But a "really secure" (better than PSTN) would be a great way of motivating deployment of IP-based e2e telephony services. Paul Elwell, John wrote: > Some of the discussion on the long thread on "TLS meaning" has led me to > seek opinions on what does indeed control the lock icon, since we seem to > have consensus that a successful SIPS request is not grounds for showing the > lock icon. > > The user surely will expect media to be secured end-to-end. By end-to-end, I > mean at least as far as the domain the user believes he/she is in > communication with. So there has to be some cryptographic assurance that the > entity with which the UA agrees keys for media security has the credentials > of the entity indicated by caller or connected party identity (From+Identity > or possibly PAI). This is probably a sufficient condition if key agreement > is carried out using D-H. If the key is transported, then an additional > condition is that the key is end-to-end encrypted, which for SDescriptions > means encrypted using S/MIME. > > But what about the presence of B2BUAs, SBCs, etc. that do not have the > credentials of the end user but nevertheless terminate media security? Here > the UA could find that it does media negotiation with service-provider.net > rather than with the end user (user@example.com). It seems the lock item > should not be displayed in this situation. Or maybe the user could be > consulted whether he/she accepts the certificate of the intermediary even > though it fails to identify the remote user. > > Another situation is where a user is trying to contact > +123456789@example.com but gets back a From/Identity indicating > +123456789@service-provider.net and media is secured as far as > service-provider.net. Does this constitute grounds for displaying the icon? > > John > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: 29 October 2006 21:26 >> To: 'EKR'; 'David R Oran' >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; >> 'Francois Audet'; 'Dean Willis' >> Subject: RE: [Sip] RE: TLS meaning >> >> >> >>> -----Original Message----- >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] >>> Sent: Saturday, October 28, 2006 9:34 AM >>> >From a security perspective, SIPS has two important properties: >>> >>> 1. It says to the client "you MUST talk to me over SSL". >> I hope it doesn't say that. I thought we had to use TLS. ;) >> >> >>> 2. It says to the proxies "I expect you to make the outgoing >>> connection with TLS". >>> >>> As Samir has observed, the second property can be provided with some >>> indicator in the SIP header. However, the first can only be provided >>> by putting the indicator in the reference which you hand >> around (i.e., >>> the SIP URI). This isn't to say it necessarily has to be a new URI >>> scheme--though it did in HTTP because HTTP doesn't have >>> parameters--but it's not clear to me that moving it to parameters >>> would really help. >> I think the part some of us are worried about is it will inherit the >> perception of https: namely that the entire path from the >> caller to the >> answerer is secure. Just because an IETF doc says it's not >> the same, and >> says it's not a lock icon, will not overcome the perception. >> Even though an >> https connection is only secure to the TLS terminator (the >> server or an >> offloader), and the back-end from there is not, the >> assumption is the owner >> of the terminator takes on the responsibility from there (if >> there is any >> responsibility). And the terminator owner wanted to secure >> it between the >> browser and the terminator, and they got that. >> >> But SIP is neither HTTP nor SMTP. The sips uri may end at a >> pstn gateway, >> or an h323 IWF, or whatever. It may become sip later, as >> well. The owner >> of the TLS terminator does not necessarily equal the owner of >> the final UAS, >> nor the owner of the answerer. How can the owner of the >> terminator have any >> responsibility for something that may happen somewhere else, >> unbeknownst to >> him? How/why would someone who types in a sips uri for their >> request not >> think it's like https? >> >> In some ways the perception problem is exacerbated by the uri >> being the sips >> scheme. If it were a require/proxy-require instead, it would >> help alleviate >> that perception problem, IMO. But then you're left with trying such a >> request without the foreknowledge of success probability that a >> business-card sips address would give you. >> >> -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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 14:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeclO-0003J5-RJ; Mon, 30 Oct 2006 14:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeclM-0003H2-WF for sip@ietf.org; Mon, 30 Oct 2006 14:25:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeclH-0006yP-6t for sip@ietf.org; Mon, 30 Oct 2006 14:25:36 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2006 11:25:30 -0800 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 k9UJPUg4032567; Mon, 30 Oct 2006 11:25:30 -0800 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 k9UJP5bj023411; Mon, 30 Oct 2006 11:25:21 -0800 (PST) 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, 30 Oct 2006 14:25:15 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 14:25:15 -0500 Message-ID: <4546519A.4040803@cisco.com> Date: Mon, 30 Oct 2006 14:25:14 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> In-Reply-To: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 19:25:15.0055 (UTC) FILETIME=[204883F0:01C6FC59] DKIM-Signature: a=rsa-sha1; q=dns; l=7957; t=1162236330; x=1163100330; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3Dr0kv6ZvsYOsda2FiXktGBPaN+fc=3D; b=dD+mogw+rvkzRBUT42JqTXMLr5UG8pGgBDcXhJcFZL87Uf0qRQf33DBaxTOL/cGXNyyAPEhh AWcGhWv0+PCaf57302jX9rsEaFLd+Ro8ISUYvrUFBlJ55gZ8r1r2ejH6; 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: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: 'IETF SIP List' , "'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 Brian Rosen wrote: > Okay, let's tackle some of these issues. > > I think in order to be useful: > sips: means yes you must carry TLS through B2BUAs and anything else that > could create an unsecure link > sips: means fail if you terminate on a gateway that interworks to a non TLS > supported protocol, and the gateway must carry TLS through a protocol that > supports TLS. > > Nothing else makes sense to me. > > For B2BUAs and SBCs and other things, I think there is a simple test: if the > ciphersuite included encryption, is the signaling encrypted end to end? How does all of the above relate to John's question? - Does having all of the above mean the little lock may be displayed? (no) - is all of the above a necessary (but insufficient) condition to being able to display the little lock? > For gateways, I think talking about interworking to non TLS secured > protocols is not what I want the sips success to mean. It's not a secure > TLS hop by hop end to end. This is especially true if the gateway is to the > PSTN. It does mean that a gateway that interworked to, say H.323 could > succeed with sips if it was possible to determine that the H.323 signaling > was TLS protected all the way. What does "all the way" mean here? If a request is addressed to sips:alice@atlanta.com, and it reaches a server holding credentials for alice@atlanta.com that acts as a UAS, does it matter what else that UAS does? It could be a device with a speaker, that plays media to a stadium full of people. Or it could be a device that broadcasts media to all who will listen. Of it might offer the media to whoever it chooses, perhaps using SIP signaling to do so. Have any of those things broken the contract of the UAS? I don't think so. It seems to me that once you have reached something authoritative for the request target, then all bets are off. The registrar and authoritative proxy have that role, though it has been muddled because we usually talk about that being a proxy rather than a UA for requests other than REGISTER. Paul > Brian > > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens.com] >> Sent: Monday, October 30, 2006 3:36 AM >> To: 'IETF SIP List' >> Subject: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) >> >> Some of the discussion on the long thread on "TLS meaning" has led me to >> seek opinions on what does indeed control the lock icon, since we seem to >> have consensus that a successful SIPS request is not grounds for showing >> the >> lock icon. >> >> The user surely will expect media to be secured end-to-end. By end-to-end, >> I >> mean at least as far as the domain the user believes he/she is in >> communication with. So there has to be some cryptographic assurance that >> the >> entity with which the UA agrees keys for media security has the >> credentials >> of the entity indicated by caller or connected party identity >> (From+Identity >> or possibly PAI). This is probably a sufficient condition if key agreement >> is carried out using D-H. If the key is transported, then an additional >> condition is that the key is end-to-end encrypted, which for SDescriptions >> means encrypted using S/MIME. >> >> But what about the presence of B2BUAs, SBCs, etc. that do not have the >> credentials of the end user but nevertheless terminate media security? >> Here >> the UA could find that it does media negotiation with service-provider.net >> rather than with the end user (user@example.com). It seems the lock item >> should not be displayed in this situation. Or maybe the user could be >> consulted whether he/she accepts the certificate of the intermediary even >> though it fails to identify the remote user. >> >> Another situation is where a user is trying to contact >> +123456789@example.com but gets back a From/Identity indicating >> +123456789@service-provider.net and media is secured as far as >> service-provider.net. Does this constitute grounds for displaying the >> icon? >> >> John >> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: 29 October 2006 21:26 >>> To: 'EKR'; 'David R Oran' >>> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; >>> 'Francois Audet'; 'Dean Willis' >>> Subject: RE: [Sip] RE: TLS meaning >>> >>> >>> >>>> -----Original Message----- >>>> From: Eric Rescorla [mailto:ekr@networkresonance.com] >>>> Sent: Saturday, October 28, 2006 9:34 AM >>>> >From a security perspective, SIPS has two important properties: >>>> >>>> 1. It says to the client "you MUST talk to me over SSL". >>> I hope it doesn't say that. I thought we had to use TLS. ;) >>> >>> >>>> 2. It says to the proxies "I expect you to make the outgoing >>>> connection with TLS". >>>> >>>> As Samir has observed, the second property can be provided with some >>>> indicator in the SIP header. However, the first can only be provided >>>> by putting the indicator in the reference which you hand >>> around (i.e., >>>> the SIP URI). This isn't to say it necessarily has to be a new URI >>>> scheme--though it did in HTTP because HTTP doesn't have >>>> parameters--but it's not clear to me that moving it to parameters >>>> would really help. >>> I think the part some of us are worried about is it will inherit the >>> perception of https: namely that the entire path from the >>> caller to the >>> answerer is secure. Just because an IETF doc says it's not >>> the same, and >>> says it's not a lock icon, will not overcome the perception. >>> Even though an >>> https connection is only secure to the TLS terminator (the >>> server or an >>> offloader), and the back-end from there is not, the >>> assumption is the owner >>> of the terminator takes on the responsibility from there (if >>> there is any >>> responsibility). And the terminator owner wanted to secure >>> it between the >>> browser and the terminator, and they got that. >>> >>> But SIP is neither HTTP nor SMTP. The sips uri may end at a >>> pstn gateway, >>> or an h323 IWF, or whatever. It may become sip later, as >>> well. The owner >>> of the TLS terminator does not necessarily equal the owner of >>> the final UAS, >>> nor the owner of the answerer. How can the owner of the >>> terminator have any >>> responsibility for something that may happen somewhere else, >>> unbeknownst to >>> him? How/why would someone who types in a sips uri for their >>> request not >>> think it's like https? >>> >>> In some ways the perception problem is exacerbated by the uri >>> being the sips >>> scheme. If it were a require/proxy-require instead, it would >>> help alleviate >>> that perception problem, IMO. But then you're left with trying such a >>> request without the foreknowledge of success probability that a >>> business-card sips address would give you. >>> >>> -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 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 30 14:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecmr-0003dz-R9; Mon, 30 Oct 2006 14:27:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecmo-0003ci-Ov for sip@ietf.org; Mon, 30 Oct 2006 14:27:06 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gecmm-00078C-Ck for sip@ietf.org; Mon, 30 Oct 2006 14:27:06 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gecmx-0006VC-1S; Mon, 30 Oct 2006 13:27:15 -0600 From: "Brian Rosen" To: "'Joel M. Halpern'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 14:26:56 -0500 Message-ID: <031f01c6fc59$5fedd9b0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> Thread-Index: Acb8VDmSXYzxDt7AQk+GWI+9WZk5mwAAi3yg 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: 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 I want sips to mean: we have protected the signaling by TLS from one end through each and every entity to the other end, with the caveat that we only have transitive trust in each leg that they are meeting this requirement. With that in mind, I think defining the B2BUA as a hop, but not the last hop is the correct interpretation. Similarly, if one end is on the PSTN, then you don't have TLS from end to end. However, if you went from SIP to H.323, but it was hop by hop TLS protected all along the path, than sips is appropriate. I think the distinction some of us are making is that while we agree that some other hop by hop security mechanisms are appropriate, and those mechanisms would use different mechanisms than all-TLS, sips meaning all TLS is useful, and deployable, and we should clarify 3261 to achieve that. I think all of us in that position also take the position that doing something else, beyond clarifying sips, is useful, and should be done, but should be called something other than sips. That is a lot more work. I don't hear any voices saying just clarify sips as TLS end to end with no further work. I hear some people disagreeing that sips meaning TLS end to end is useful. Some of those people want to simply deprecate sips and define something else. Others want to redefine sips to be something else. The something else is the same something else I want. I think we all tend to be agreeing on what that something else should look like: it should describe desired security properties, it should allow any suitable mechanism to achieve that goal, it should involve some use of Require/Supported. Brian > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Monday, October 30, 2006 1:46 PM > To: 'IETF SIP List' > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) > > I have removed most of the attribution below because the question of > who said it, or what exactly he said, is not my point at the moment. > > At 01:22 PM 10/30/2006, Someone wrote: > >Okay, let's tackle some of these issues. > > > >I think in order to be useful: > >sips: means .... > > > >Nothing else makes sense to me. > > Having had several off line discussions with people who know their > stuff very well about this SIPS issue, what has become very clear to > me is that different participants have very different mental models > of the relative roles and responsibilities of the proxies and the > initiating / terminating UAs in the SIP exchanges. And different > understandings of what the expressed user desire is when they say "sips:". > > This then results in people saying "nothing else makes sense to me." > In fact, I still am having trouble understanding some of the points > of view, because of this model conflict. (And I will readily admit > that my mental model of what's going on may be wrong. But I can't > seem to get to another one.) > > We then end up talking past each other. > > Yours, > Joel M. Halpern > > PS: I am deliberately being a bit vague on the model mismatches for > two reasons. Firstly, I think there are many more mismatches than > just the ones between me and my correspondents. Secondly, I really > don't want to mischaracterise other people's arguments. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 30 14:37:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecuf-00014b-NH; Mon, 30 Oct 2006 14:35:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecue-00014V-U7 for sip@ietf.org; Mon, 30 Oct 2006 14:35:12 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gecue-0007zS-E8 for sip@ietf.org; Mon, 30 Oct 2006 14:35:12 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Gecum-0002gQ-4c; Mon, 30 Oct 2006 13:35:20 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Elwell, John'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 14:34:56 -0500 Message-ID: <032201c6fc5a$80ee87d0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <45464E61.6030305@cisco.com> Thread-Index: Acb8V6zpGT90V9fFRLWrU5HwIC7jSgAAbOhQ 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: ec7c6dab5a62df223002ae71b5179d41 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 pretty much agree with John. I think the lock should mean BOTH the signaling and the media are protected at least hop by hop. I think sips is therefore a necessary, but insufficient mechanism. A really interesting question is whether S/MIME is acceptable as a sufficient mechanism. It surely is for some parts of signaling, but as a practical answer, it can't protect all of the signaling. I think we all agree SRTP is sufficient, but we don't yet agree on what a sufficient key management mechanism for SRTP is. I think if you have used S/MIME or TLS on the signaling, that any of the key mechanisms I know are sufficient. I'm not sure how we deal with SBCs in the media path. I guess if the media was protected end to end, even with a middlebox, then I think the lock icon is okay. I think the retargeting of +15551212@example.com to +15551212@sp.net is an acceptable condition for displaying the lock icon. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, October 30, 2006 2:11 PM > To: Elwell, John > Cc: 'IETF SIP List' > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) > > I support John here. As stupid as it might seem, I think this little > thing is likely to be very important. And figuring out what it takes to > have it is a way at getting to underlying requirements for security in > the protocol. Perhaps there are also other requirements for security, > but at least this would provide one source. > > So far I have heard that having a SIPS connection doesn't imply that one > can show this lock icon. What isn't yet clear to me is if that means > that SIPS is a necessary but insufficient condition, or if SIPS is in > fact not even helpful for providing it. I suspect it isn't even helpful. > If not, then what *is* driving the requirements for SIPS? > > I think I would also extend John's proposal a bit. I think there *may* > need to be different levels of security, where the lock icon corresponds > to one of them. But this is a slippery slope, because if there are too > many they become confusing to users. But too few of the wrong ones may > not be useful in practice. > > For instance, it may be that there is a need for "PSTN quality" > security. (I imagine that *ought* to be the same as "none", but in > practice I think the PSTN level security is better than basic > unsecured-sip-over-internet security, so knowing you had this when > connected to the PSTN could be helpful.) But a "really secure" (better > than PSTN) would be a great way of motivating deployment of IP-based e2e > telephony services. > > Paul > > Elwell, John wrote: > > Some of the discussion on the long thread on "TLS meaning" has led me to > > seek opinions on what does indeed control the lock icon, since we seem > to > > have consensus that a successful SIPS request is not grounds for showing > the > > lock icon. > > > > The user surely will expect media to be secured end-to-end. By end-to- > end, I > > mean at least as far as the domain the user believes he/she is in > > communication with. So there has to be some cryptographic assurance that > the > > entity with which the UA agrees keys for media security has the > credentials > > of the entity indicated by caller or connected party identity > (From+Identity > > or possibly PAI). This is probably a sufficient condition if key > agreement > > is carried out using D-H. If the key is transported, then an additional > > condition is that the key is end-to-end encrypted, which for > SDescriptions > > means encrypted using S/MIME. > > > > But what about the presence of B2BUAs, SBCs, etc. that do not have the > > credentials of the end user but nevertheless terminate media security? > Here > > the UA could find that it does media negotiation with service- > provider.net > > rather than with the end user (user@example.com). It seems the lock item > > should not be displayed in this situation. Or maybe the user could be > > consulted whether he/she accepts the certificate of the intermediary > even > > though it fails to identify the remote user. > > > > Another situation is where a user is trying to contact > > +123456789@example.com but gets back a From/Identity indicating > > +123456789@service-provider.net and media is secured as far as > > service-provider.net. Does this constitute grounds for displaying the > icon? > > > > John > > > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >> Sent: 29 October 2006 21:26 > >> To: 'EKR'; 'David R Oran' > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > >> 'Francois Audet'; 'Dean Willis' > >> Subject: RE: [Sip] RE: TLS meaning > >> > >> > >> > >>> -----Original Message----- > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > >>> Sent: Saturday, October 28, 2006 9:34 AM > >>> >From a security perspective, SIPS has two important properties: > >>> > >>> 1. It says to the client "you MUST talk to me over SSL". > >> I hope it doesn't say that. I thought we had to use TLS. ;) > >> > >> > >>> 2. It says to the proxies "I expect you to make the outgoing > >>> connection with TLS". > >>> > >>> As Samir has observed, the second property can be provided with some > >>> indicator in the SIP header. However, the first can only be provided > >>> by putting the indicator in the reference which you hand > >> around (i.e., > >>> the SIP URI). This isn't to say it necessarily has to be a new URI > >>> scheme--though it did in HTTP because HTTP doesn't have > >>> parameters--but it's not clear to me that moving it to parameters > >>> would really help. > >> I think the part some of us are worried about is it will inherit the > >> perception of https: namely that the entire path from the > >> caller to the > >> answerer is secure. Just because an IETF doc says it's not > >> the same, and > >> says it's not a lock icon, will not overcome the perception. > >> Even though an > >> https connection is only secure to the TLS terminator (the > >> server or an > >> offloader), and the back-end from there is not, the > >> assumption is the owner > >> of the terminator takes on the responsibility from there (if > >> there is any > >> responsibility). And the terminator owner wanted to secure > >> it between the > >> browser and the terminator, and they got that. > >> > >> But SIP is neither HTTP nor SMTP. The sips uri may end at a > >> pstn gateway, > >> or an h323 IWF, or whatever. It may become sip later, as > >> well. The owner > >> of the TLS terminator does not necessarily equal the owner of > >> the final UAS, > >> nor the owner of the answerer. How can the owner of the > >> terminator have any > >> responsibility for something that may happen somewhere else, > >> unbeknownst to > >> him? How/why would someone who types in a sips uri for their > >> request not > >> think it's like https? > >> > >> In some ways the perception problem is exacerbated by the uri > >> being the sips > >> scheme. If it were a require/proxy-require instead, it would > >> help alleviate > >> that perception problem, IMO. But then you're left with trying such a > >> request without the foreknowledge of success probability that a > >> business-card sips address would give you. > >> > >> -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 > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 30 14:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecvs-0001cd-Sn; Mon, 30 Oct 2006 14:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gecvr-0001bh-Ip for sip@ietf.org; Mon, 30 Oct 2006 14:36:27 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gecvm-00085t-68 for sip@ietf.org; Mon, 30 Oct 2006 14:36:27 -0500 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 k9UJaJs29936 for ; Mon, 30 Oct 2006 14:36:19 -0500 (EST) 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] RE: TLS meaning Date: Mon, 30 Oct 2006 13:36:14 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2A1D3@zrc2hxm0.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918069B44B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyAAPq8mEA== From: "Francois Audet" To: "Drage, Keith \(Keith\)" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Thank you very much for stepping in. I will do exactly as per the directive in this email.=20 > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 > Sent: Sunday, October 29, 2006 3:50 PM > To: Audet, Francois (SC100:3055); IETF SIP List > Subject: RE: [Sip] RE: TLS meaning >=20 > As WG chair: >=20 > Please bear in mind: >=20 > 1) The WG agreed at the last meeting that the scope of this > document is an informational document. The minutes clearly=20 > state this, and the charter as follows: >=20 > Mar 2007 Guidelines for use of SIP security to WGLC (Informational) >=20 > Jun 2007 Guidelines for use of SIP security to IESG (Informational) >=20 > Was updated to say this. (Both these have been presented to=20 > the mailing list without comment in reasonable time so this=20 > as far as I am concerned is a decision. Therefore this=20 > document in itself does not deprecate SIPS, and we will need=20 > to decide to do this later. >=20 > 2) This document does not update RFC 3261 it itself. Francois > please update your abstract because this is not what this=20 > document does. > You may also want to investigate the RFC 2119 language as a result. > There will have to be other documents that update RFC3261=20 > that are not this document. Note that we did agree that this=20 > document was the basis of this work, and therefore it should=20 > be reissued as a -00 SIP WG document. >=20 > 3) What this document is/was intended to do was: >=20 > - clearly document what we had now, i.e. identify what occurred if > the user attempted xyd, and what level of security they did=20 > get if they attempted xyz. >=20 > - identify what improvements or changes to our current SIP > security, as defined in RFC 3261, where therefore required.=20 > These could fall into the following: >=20 > A) creation of new mechanisms that provided a level of security > that is not provided by the existing mechanisms. I this case=20 > we need to clearly identify the improvement and motivate why=20 > it is needed. >=20 > B) changes to existing mechanisms to make them work. In this case, > we need to clearly state why the existing mechanism is=20 > broken, i.e. not interoperable to produce a deterministic result. >=20 > C) deprecation of existing mechanism - the one we seem to be > discussing here. In this case, I (and we are the ones that=20 > have to justify this to the IESG) want to understand firstly=20 > why the existing mechanism is harmful to implementations if=20 > it continues to exist, and also understand the impact on the=20 > existing implementation community if we do deprecate.=20 > Therefore what this discussion must do is identify these=20 > reasons and put them in the document. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 27 October 2006 17:12 > > To: IETF SIP List > > Subject: RE: [Sip] RE: TLS meaning > >=20 > > In case people having noticed, it is looking like we are having a=20 > > mailing list hum on the following 2 questions: > >=20 > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > >=20 > > 2 - Do you favour getting rid of the last-hop-exception=20 > rule (yes/no) > >=20 > >=20 > > Note: Voting Yes on 2 does not necessarily imply you are=20 > voting No on=20 > > 1, but it will only make sense if sips is not deprecated. > >=20 > > I'm keeping track of the vote. > >=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 From sip-bounces@ietf.org Mon Oct 30 14:38:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecwD-0001tX-7H; Mon, 30 Oct 2006 14:36:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GecwC-0001sh-3D for sip@ietf.org; Mon, 30 Oct 2006 14:36:48 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gecw8-000888-Pd for sip@ietf.org; Mon, 30 Oct 2006 14:36:48 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1047650ugd for ; Mon, 30 Oct 2006 11:36:43 -0800 (PST) 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=QyQetUTypDKVIXrLvg5gdAXl047EZxGcM6jdVKkeOF3uSJPtOSgYK3KArCys0XoLt37xqIVWK94MqlU8YthOGYT685bCghW4fExlSNtGeBqfFDZybgbMygnc+v5L8zsBXHQiU1pRkdxJ7S+741sEPimMkmEHENbMgAbH8bxFnZU= Received: by 10.78.203.15 with SMTP id a15mr5457232hug; Mon, 30 Oct 2006 11:36:42 -0800 (PST) Received: by 10.78.200.9 with HTTP; Mon, 30 Oct 2006 11:36:42 -0800 (PST) Message-ID: <953beacc0610301136u6ddbec7chcb565b807e053b07@mail.gmail.com> Date: Mon, 30 Oct 2006 12:36:42 -0700 From: "Rohan Mahy" To: "Fredrik Thulin" Subject: Re: [Sip] One big concern with outbound-05 In-Reply-To: <07ff01c6fc3e$639419a0$191e0bc1@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <06c601c6fc18$432daf80$191e0bc1@it.su.se> <079301c6fc28$afe2b700$191e0bc1@it.su.se> <953beacc0610300805k27a8e5ffq261949577b25f22b@mail.gmail.com> <07ff01c6fc3e$639419a0$191e0bc1@it.su.se> 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Exactly. thx, -r On 10/30/06, Fredrik Thulin wrote: > Rohan Mahy wrote: > > Hi Fredrik, > > > > Yes, the scenario you described will work. > > Thanks - then I'm very happy with the current Outbound. > > Just to double check, it will work without requests forwarded from the > Authoritative proxy, towards the UA, going through the edge proxy of > sip-p.net? > > I mean, ep1.sip-p.net won't add itself to the Path of the REGISTER, > since it knows that the Authoritative proxy can reach ep1/ep2.isp.net > directly? > > Thanks again > > /Fredrik > > > > > > ep1.isp.net (ep1.sip-p.net) > > UA --NAT-- ------- ep.sip-p.net -- Authoritative proxy > > / > > ep2.isp.net (ep2.sip-p.net) registrar > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 14:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ged84-0001Xm-Gb; Mon, 30 Oct 2006 14:49:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ged83-0001Xh-SU for sip@ietf.org; Mon, 30 Oct 2006 14:49:03 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ged7y-0000v4-Dc for sip@ietf.org; Mon, 30 Oct 2006 14:49:03 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.7/8.13.7) with ESMTP id k9UJmu1m014819; Mon, 30 Oct 2006 12:48:56 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Comments on draft-ietf-sip-outbound-05 Date: Mon, 30 Oct 2006 12:48:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-ietf-sip-outbound-05 Thread-Index: Acb8PLJNRUwo7aI7RbuYoO4KqxJ76wAHwuxA From: "Kevin Johns" To: "Rohan Mahy" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 What about the proposed changes to section 5.3? It is not listed in your email so does that mean it was accepted without comment? (If so great as I agreed with the change in wording as well.) > 5.3 Forwarding Requests > > Otherwise, if the top- > most Route header refers to the Edge Proxy and contains a valid=20 > flow > identifier token created by this proxy, the proxy MUST remove the=20 > the > Route header and forward the request over the flow that received=20 > the > REGISTER request that caused the flow identifier token to be=20 > created. I suggest the following sentence instead : "Otherwise, if the top-most Route header refers to the Edge Proxy and contains a valid flow identifier token created by this proxy, the proxy MUST remove the Route header and forward the request over the flow identified by the flow token". If you don't like my text, then at least note there is a "the the" in the original sentence. -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Monday, October 30, 2006 9:00 AM To: Fredrik Thulin Cc: sip@ietf.org Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05 Hi Fredrik, I like your proposed text. I'm pasting all these into the draft unless otherwise noted. On 10/30/06, Fredrik Thulin wrote: > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > Likewise if > > the REGISTER request visited an edge proxy, but no Path header=20 > > field > > values are present, the registrar MUST ignore the reg-id parameter. > > Just to check: Would a registrar know this because there were more=20 > than one Via header in the request, but no Path header? Yes. > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > For a binding with an > > instance-id, the registrar still stores the Contact header field > > value URI with the binding, but does not consider the Contact URI > > for > > comparison purposes. > > Shouldn't that be "For a binding with an instance-id and a reg-id, the > ..."? No, this sentence was added to allow implementations to fetch a GRUU (which needs an instance-id) without implementing outbound (which needs a reg-id). > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > In addition to the normal information stored in the binding record, > > some additional information needs to be stored for any registration > > that contains a reg-id header parameter in the Contact header field > > value. > > This should be "contains an instance-id and a reg-id header parameter" > I believe. If there was only a reg-id parameter, it should be ignored. Yes, good catch. > > 6. Registrar Mechanisms: Processing REGISTER Requests > > > > ... MUST implement support the STUN > > Either implement or support. "MUST implement the STUN keepalive mechanism described in Section x of this document." > > 8. STUN Keepalive Processing > > > > Note that UACs MUST NOT > > use an ambiguous configuration option such as "Work through NATs?" > > or > > "Do Keepalives?" to imply next hop STUN support. > > I think this sentence should be removed. I don't think there is a=20 > single way to ask the end user if STUN keepalives should be sent or=20 > not that would actually make sense to an average end user. That=20 > sentence is no longer needed after the new text explaining that a user > agent must actually verify STUN support. I also think it is out of=20 > scope for Outbound to tell implementors how they should make their=20 > user interfaces. I added this at the request of other folks in the WG. The normative language is just "MUST NOT use an ambiguous configuration option". I'm inclined to leave this sentence or reword it unless the folks who were originally concerned also no longer think it is necessary. > > 8. STUN Keepalive Processing > > Generally regarding the mechanisms in this section, I am a bit unsure=20 > about if the case where a next-hop actually _stops_ supporting STUN is > handled with enough care. One might say that it would be very seldom=20 > that providers actually downgrade their edge proxys to something that=20 > no longer supports STUN, but think for example if I have my wifi phone > configured with 192.168.0.1 supporting STUN keepalives. That might=20 > work just fine with my own wireless access point, but perhaps not with > someone elses, that my phone ends up connected to. > > I think there should be text saying that support has to be re-verified > after some period of time without successfull STUN transactions.=20 > Perhaps something like : > > "If a destination previously validated to support STUN keepalives does > not respond to any STUN keepalives sent for 36000 seconds (ten hours), > then the validation is to be considered revoked and support will have=20 > to be verified in the same way as if the next-hop had never been=20 > validated." Ugh. I'd like to think about this a bit more. > > 8. STUN Keepalive Processing > > If a client sends a REGISTER with "Supported: path", and receives a=20 > 200 response with a Path vector in it, it could look for ";ob" in the=20 > first Path header value, and use that as an explicit indication that=20 > it would be OK to send STUN messages to the next hop, right? Of=20 > course, the text in this section about actually validating STUN=20 > support fot the next hop still applies. Probably, but I needed to make the section on STUN processing relatively autonomous. I think I will bring this up at the meeting. 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 Mon Oct 30 15:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedLx-0006ly-TT; Mon, 30 Oct 2006 15:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedLw-0006lp-0K for sip@ietf.org; Mon, 30 Oct 2006 15:03:24 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedLv-0002Gg-94 for sip@ietf.org; Mon, 30 Oct 2006 15:03:23 -0500 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 k9UK3Is22510; Mon, 30 Oct 2006 15:03:18 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 14:03:12 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC2A276@zrc2hxm0.corp.nortel.com> In-Reply-To: <45464E61.6030305@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8V8eJg0q75zb6RA22y84zio7CLAAAhsOw From: "Francois Audet" To: "Paul Kyzivat" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 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 really don't understand why people keep on bringing the padlock thing again in the context of sips. In a request-URI, sips is merely an indication that it is requested that all the hops (except possibly the last one) forward this request over TLS.=20 RFC3261 uses a different URI scheme for that purpose as opposed to a Require header, but that's water under the bridge. That functionality is useful. Many of us have explained over and over why being able to request that a request be sent securely over TLS is useful. There is no implication of padlock icons here, neigher for the sender or the receiver. There are many aspects to security, and it's not clear to me that the role of IETF is to define the meaning of a padlock. Regardles, I can think of the following attribute:=20 - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? - Are selected parts of the SIP message itself and MIME bodies (including SDP)=20 integrity protected end-to-end using SIP Identity (as per RFC 4474)? - Are the whole SIP message itself and MIME bodies (including SDP) integrity=20 protected end-to-end using S/MIME (as per RFC 3993)? - Is media encrypted end-to-end using SRTP? - Is the key negotiation used for that secured end-to-end using encryption (e.g.,=20 MIKEY, SDESC with S/MIME). - Is the identity of the user sending the request secured with sip-identity (RFC 4474)? - Are request mapped to a non-SIP network considered "secure" (e.g., PSTN, H.323, etc.)? - Can we protect against B2BUA and the likes?=20 - etc. In short, there are many aspects to this, including (but not limited to): - Authentication of users - Integrity protection - Encryption of signalling - Encryption of media - End-to-end versus hop-by-hop - Hop-of to another network (e.g., PSTN, H.323, etc.)=20 - What cyphersuites are used - etc. It is not clear to me at all that we (SIP WG) can specify what the padlock icon should be.=20 Different network deployment may wish to convey different information to end-users. In some deployment, you may want an indication that everything is encrypted/authenticated end-to-end (security, media, identity, etc.) using a consolidated icon. In other deployment, maybe hop-by-hop is the desired behavior (e.g., inside an enterprise where lawful intercept=20 may be view as secure). In some other deployment, you amy want different padlock icons for different security properties. Or different levels of security. The point is, this is NOT SIPS. It's something else. If we decide to tackle it or not is another issue. I personally think it is a pretty tall order, and I'm not sure it's the mandate of IETF. For now, I just want to ensure that we don't confuse padlock with SIPS. Cheers. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, October 30, 2006 11:11 AM > To: Elwell, John > Cc: 'IETF SIP List' > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > I support John here. As stupid as it might seem, I think this=20 > little thing is likely to be very important. And figuring out=20 > what it takes to have it is a way at getting to underlying=20 > requirements for security in the protocol. Perhaps there are=20 > also other requirements for security, but at least this would=20 > provide one source. >=20 > So far I have heard that having a SIPS connection doesn't=20 > imply that one can show this lock icon. What isn't yet clear=20 > to me is if that means that SIPS is a necessary but=20 > insufficient condition, or if SIPS is in fact not even=20 > helpful for providing it. I suspect it isn't even helpful.=20 > If not, then what *is* driving the requirements for SIPS? >=20 > I think I would also extend John's proposal a bit. I think=20 > there *may* need to be different levels of security, where=20 > the lock icon corresponds to one of them. But this is a=20 > slippery slope, because if there are too many they become=20 > confusing to users. But too few of the wrong ones may not be=20 > useful in practice. >=20 > For instance, it may be that there is a need for "PSTN quality"=20 > security. (I imagine that *ought* to be the same as "none",=20 > but in practice I think the PSTN level security is better=20 > than basic unsecured-sip-over-internet security, so knowing=20 > you had this when connected to the PSTN could be helpful.)=20 > But a "really secure" (better than PSTN) would be a great way=20 > of motivating deployment of IP-based e2e telephony services. >=20 > Paul >=20 > Elwell, John wrote: > > Some of the discussion on the long thread on "TLS meaning"=20 > has led me=20 > > to seek opinions on what does indeed control the lock icon,=20 > since we=20 > > seem to have consensus that a successful SIPS request is=20 > not grounds=20 > > for showing the lock icon. > >=20 > > The user surely will expect media to be secured end-to-end. By=20 > > end-to-end, I mean at least as far as the domain the user believes=20 > > he/she is in communication with. So there has to be some=20 > cryptographic=20 > > assurance that the entity with which the UA agrees keys for media=20 > > security has the credentials of the entity indicated by caller or=20 > > connected party identity (From+Identity or possibly PAI). This is=20 > > probably a sufficient condition if key agreement is carried=20 > out using=20 > > D-H. If the key is transported, then an additional=20 > condition is that=20 > > the key is end-to-end encrypted, which for SDescriptions=20 > means encrypted using S/MIME. > >=20 > > But what about the presence of B2BUAs, SBCs, etc. that do=20 > not have the=20 > > credentials of the end user but nevertheless terminate=20 > media security?=20 > > Here the UA could find that it does media negotiation with=20 > > service-provider.net rather than with the end user=20 > (user@example.com).=20 > > It seems the lock item should not be displayed in this=20 > situation. Or=20 > > maybe the user could be consulted whether he/she accepts the=20 > > certificate of the intermediary even though it fails to=20 > identify the remote user. > >=20 > > Another situation is where a user is trying to contact > > +123456789@example.com but gets back a From/Identity indicating=20 > > +123456789@service-provider.net and media is secured as far as > > service-provider.net. Does this constitute grounds for=20 > displaying the icon? > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >> Sent: 29 October 2006 21:26 > >> To: 'EKR'; 'David R Oran' > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; 'Francois=20 > >> Audet'; 'Dean Willis' > >> Subject: RE: [Sip] RE: TLS meaning > >> > >> > >> > >>> -----Original Message----- > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > >>> Sent: Saturday, October 28, 2006 9:34 AM > >>> >From a security perspective, SIPS has two important properties: > >>> > >>> 1. It says to the client "you MUST talk to me over SSL". > >> I hope it doesn't say that. I thought we had to use TLS. ;) > >> > >> > >>> 2. It says to the proxies "I expect you to make the outgoing > >>> connection with TLS". > >>> > >>> As Samir has observed, the second property can be=20 > provided with some=20 > >>> indicator in the SIP header. However, the first can only=20 > be provided=20 > >>> by putting the indicator in the reference which you hand > >> around (i.e., > >>> the SIP URI). This isn't to say it necessarily has to be=20 > a new URI=20 > >>> scheme--though it did in HTTP because HTTP doesn't have=20 > >>> parameters--but it's not clear to me that moving it to parameters=20 > >>> would really help. > >> I think the part some of us are worried about is it will=20 > inherit the=20 > >> perception of https: namely that the entire path from the=20 > caller to=20 > >> the answerer is secure. Just because an IETF doc says=20 > it's not the=20 > >> same, and says it's not a lock icon, will not overcome the=20 > >> perception. > >> Even though an > >> https connection is only secure to the TLS terminator (the=20 > server or=20 > >> an offloader), and the back-end from there is not, the=20 > assumption is=20 > >> the owner of the terminator takes on the responsibility from there=20 > >> (if there is any responsibility). And the terminator=20 > owner wanted to=20 > >> secure it between the browser and the terminator, and they=20 > got that. > >> > >> But SIP is neither HTTP nor SMTP. The sips uri may end at a pstn=20 > >> gateway, or an h323 IWF, or whatever. It may become sip later, as=20 > >> well. The owner of the TLS terminator does not=20 > necessarily equal the=20 > >> owner of the final UAS, nor the owner of the answerer. =20 > How can the=20 > >> owner of the terminator have any responsibility for something that=20 > >> may happen somewhere else, unbeknownst to him? How/why=20 > would someone=20 > >> who types in a sips uri for their request not think it's=20 > like https? > >> > >> In some ways the perception problem is exacerbated by the=20 > uri being=20 > >> the sips scheme. If it were a require/proxy-require instead, it=20 > >> would help alleviate that perception problem, IMO. But=20 > then you're=20 > >> left with trying such a request without the foreknowledge=20 > of success=20 > >> probability that a business-card sips address would give you. > >> > >> -hadriel > >> > >> > >> _______________________________________________ > >> 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 From sip-bounces@ietf.org Mon Oct 30 15:06:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedNa-0007GP-Ub; Mon, 30 Oct 2006 15:05:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedNZ-0007GF-Cy for sip@ietf.org; Mon, 30 Oct 2006 15:05:05 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedNR-0002OZ-OD for sip@ietf.org; Mon, 30 Oct 2006 15:05:05 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E269654B; Mon, 30 Oct 2006 21:04:41 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 21:04:42 +0100 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] One big concern with outbound-05 Date: Mon, 30 Oct 2006 21:04:38 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB59404549211@esealmw113.eemea.ericsson.se> In-Reply-To: <079301c6fc28$afe2b700$191e0bc1@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] One big concern with outbound-05 Thread-Index: Acb8KVB45oumQb7hTzWz5sPTCGJJXQANDPIA From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , X-OriginalArrivalTime: 30 Oct 2006 20:04:42.0041 (UTC) FILETIME=[A31DEA90:01C6FC5E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 don't think you can assume that the sip-p.net proxies won't add Path headers. Path is used for other purposes than outbound, so there may be many non-outbound related reasons why proxies add Path. For example, in IMS the P-CSCF could be the edge proxy, but then you can have other intermediate nodes between the P-CSCF and home S-CSCF (registrar) that insert Path. Regards, Christer =20 > -----Original Message----- > From: Fredrik Thulin [mailto:ft@it.su.se]=20 > Sent: 30. lokakuuta 2006 15:39 > To: sip@ietf.org > Subject: Re: [Sip] One big concern with outbound-05 >=20 > Fredrik Thulin wrote: > ... > > I STRONGLY object to the principle in Outbound that when a=20 > request is=20 > > received destined for the UA, the proxys on the way MUST=20 > use the very=20 > > same connection on every hop. On the last hop (between=20 > ep1/ep2.isp.net=20 > > and the UA), naturally the same flow has to be used, but not for=20 > > example between the EP's of isp.net and sip-p.net! It is not at all=20 > > unreasonable that practically all SIP servers have global=20 > > connectivity, even though clearly it was not reasonable to=20 > expect all=20 > > user agents to have one. >=20 > I think I will have to take all of this back. When going=20 > through my print out of the draft with comments in the=20 > margins, to write about the other questions/comments I had I=20 > think I realize that you actually _have_ loosened the rules=20 > in outbound-05 to not demand proxys with global reachability=20 > to use the very same flow. >=20 > Can I just verify this by asking if the following scenario=20 > would work with Outbound-05? >=20 >=20 > ep1.isp.net (ep1.sip-p.net) > UA --NAT-- ------- ep.sip-p.net --=20 > Authoritative proxy / > ep2.isp.net (ep2.sip-p.net) registrar >=20 >=20 > The UA sets up one Outbound flow to ep1.isp.net, and one to=20 > ep2.isp.net.=20 > It sends a REGISTER on both flows, and when these reach the=20 > Authoritative proxy / registrar they look like this : >=20 > Request #1 : >=20 > REGISTER sip:sip-p.net > Via: SIP/2.0/TCP ep1.isp.net;branch=3D... > Via: SIP/2.0/TCP ep1.sip-p.net;branch=3D... > Path: > From: <...> > ... >=20 > Request #2 : >=20 > REGISTER sip:sip-p.net > Via: SIP/2.0/TCP ep2.isp.net;branch=3D... > Via: SIP/2.0/TCP ep1.sip-p.net;branch=3D... > Path: > From: <...> > ... >=20 > So the edge proxys of sip-p.net didn't add any Path headers, because=20 > they knew that ep1.isp.net was globally reachable, and the=20 > Authoritative=20 > proxy didn't add itself to the Path vector before storing the=20 > location=20 > binding? >=20 > If this is how it would work, then I am totally happy with it. >=20 > /Fredrik >=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 Oct 30 15:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gee9v-0006y0-R1; Mon, 30 Oct 2006 15:55:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gee9t-0006xZ-Mg for sip@ietf.org; Mon, 30 Oct 2006 15:55:01 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gee9q-0007C3-26 for sip@ietf.org; Mon, 30 Oct 2006 15:55:01 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2006 12:54:57 -0800 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 k9UKsv1e012069; Mon, 30 Oct 2006 15:54:57 -0500 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 k9UKsvDM021236; Mon, 30 Oct 2006 15:54:57 -0500 (EST) 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, 30 Oct 2006 15:54:57 -0500 Received: from [161.44.79.182] ([161.44.79.182]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 15:54:56 -0500 Message-ID: <454666A0.9080005@cisco.com> Date: Mon, 30 Oct 2006 15:54:56 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Francois Audet Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <1ECE0EB50388174790F9694F77522CCF0DC2A276@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC2A276@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2006 20:54:56.0830 (UTC) FILETIME=[A81235E0:01C6FC65] DKIM-Signature: a=rsa-sha1; q=dns; l=12385; t=1162241697; x=1163105697; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning) |To:Francois=20Audet=20; X=v=3Dcisco.com=3B=20h=3Dr0kv6ZvsYOsda2FiXktGBPaN+fc=3D; b=DSYwAU5mOLbRCMJURyE3dBO1e7LdsldVmT1fK9TsO2QAafOOeVUk2YvNBrM9LT7pnDK0ERD/ KT8jOHaxFvk5QmitE8BRGbBiqEkqoIHc2kQ6wJrQUINiWbwypUqLTali; 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: 52f402fbded34a6df606921f56b8bdd8 Cc: IETF SIP List , "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 Francois Audet wrote: > I really don't understand why people keep on bringing the padlock thing > again in the context of sips. The subject line was changed to protect the guilty (er - innocent). :-) Seriously, while related its not exactly the same subject, so don't take it personally. > In a request-URI, sips is merely an indication that it is requested that > all the hops (except possibly the last one) forward this request over > TLS. > RFC3261 uses a different URI scheme for that purpose as opposed to a > Require > header, but that's water under the bridge. That functionality is useful. I think you have a good handle on having a clear definition of what SIPS means. IMO the question is, once that is settled, is how useful and important that is. > Many of us have explained over and over why being able to request that > a request be sent securely over TLS is useful. Does it solve enough problems to be worth the trouble of getting deployed? > There is no implication of padlock icons here, neigher for the sender or > the receiver. > > There are many aspects to security, and it's not clear to me that the > role of IETF is to define the meaning of a padlock. Regardles, I can > think of the following attribute: It may not be necessary for the ietf to define this, or at least that it make the one and only definition. But it could be important to establish a framework within which it is clear how to make such definitions, and perhaps to make one definition to serve as a proof of concept and to help in understanding what dependencies there are on mechanisms such as SIPS. > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? > > - Are selected parts of the SIP message itself and MIME bodies > (including SDP) > integrity protected end-to-end using SIP Identity (as per RFC 4474)? > > - Are the whole SIP message itself and MIME bodies (including SDP) > integrity > protected end-to-end using S/MIME (as per RFC 3993)? > > - Is media encrypted end-to-end using SRTP? > > - Is the key negotiation used for that secured end-to-end using > encryption (e.g., > MIKEY, SDESC with S/MIME). > > - Is the identity of the user sending the request secured with > sip-identity (RFC 4474)? > > - Are request mapped to a non-SIP network considered "secure" (e.g., > PSTN, H.323, etc.)? > > - Can we protect against B2BUA and the likes? > - etc. I think I agree with these, though it may turn out that in practice all aren't necessary. Getting an idea of what it means to "protect against a B2BUA" could be very interesting. > In short, there are many aspects to this, including (but not limited > to): > > - Authentication of users > > - Integrity protection > > - Encryption of signalling > > - Encryption of media > > - End-to-end versus hop-by-hop > > - Hop-of to another network (e.g., PSTN, H.323, etc.) > > - What cyphersuites are used > > - etc. > > It is not clear to me at all that we (SIP WG) can specify what the > padlock icon should be. > Different network deployment may wish to convey different information to > end-users. That could lead to some nasty interoperability issues when considering "networks" that interconnect. Maybe it is inevitable that there will be limited or no real security in cases like this, but I think there will be demand for some. (For really disconnected networks, such as for military command and control, interop probably isn't an issue and a special definition would be appropriate.) > In some deployment, you may want an indication that everything is > encrypted/authenticated > end-to-end (security, media, identity, etc.) using a consolidated icon. > In other deployment, > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise > where lawful intercept > may be view as secure). > > In some other deployment, you amy want different padlock icons for > different security > properties. Or different levels of security. > > The point is, this is NOT SIPS. It's something else. If we decide to > tackle it or not > is another issue. I personally think it is a pretty tall order, and I'm > not sure > it's the mandate of IETF. For now, I just want to ensure that we don't > confuse > padlock with SIPS. I agree it probably isn't within the current charter. And I don't know where it would fall in a priority list. But I think it is something that will eventually need to be done, and I don't see who other than the ietf would be appropriate to do a general framework that could support interoperability over the internet. Paul > Cheers. > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, October 30, 2006 11:11 AM >> To: Elwell, John >> Cc: 'IETF SIP List' >> Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: >> TLS meaning) >> >> I support John here. As stupid as it might seem, I think this >> little thing is likely to be very important. And figuring out >> what it takes to have it is a way at getting to underlying >> requirements for security in the protocol. Perhaps there are >> also other requirements for security, but at least this would >> provide one source. >> >> So far I have heard that having a SIPS connection doesn't >> imply that one can show this lock icon. What isn't yet clear >> to me is if that means that SIPS is a necessary but >> insufficient condition, or if SIPS is in fact not even >> helpful for providing it. I suspect it isn't even helpful. >> If not, then what *is* driving the requirements for SIPS? >> >> I think I would also extend John's proposal a bit. I think >> there *may* need to be different levels of security, where >> the lock icon corresponds to one of them. But this is a >> slippery slope, because if there are too many they become >> confusing to users. But too few of the wrong ones may not be >> useful in practice. >> >> For instance, it may be that there is a need for "PSTN quality" >> security. (I imagine that *ought* to be the same as "none", >> but in practice I think the PSTN level security is better >> than basic unsecured-sip-over-internet security, so knowing >> you had this when connected to the PSTN could be helpful.) >> But a "really secure" (better than PSTN) would be a great way >> of motivating deployment of IP-based e2e telephony services. >> >> Paul >> >> Elwell, John wrote: >>> Some of the discussion on the long thread on "TLS meaning" >> has led me >>> to seek opinions on what does indeed control the lock icon, >> since we >>> seem to have consensus that a successful SIPS request is >> not grounds >>> for showing the lock icon. >>> >>> The user surely will expect media to be secured end-to-end. By >>> end-to-end, I mean at least as far as the domain the user believes >>> he/she is in communication with. So there has to be some >> cryptographic >>> assurance that the entity with which the UA agrees keys for media >>> security has the credentials of the entity indicated by caller or >>> connected party identity (From+Identity or possibly PAI). This is >>> probably a sufficient condition if key agreement is carried >> out using >>> D-H. If the key is transported, then an additional >> condition is that >>> the key is end-to-end encrypted, which for SDescriptions >> means encrypted using S/MIME. >>> But what about the presence of B2BUAs, SBCs, etc. that do >> not have the >>> credentials of the end user but nevertheless terminate >> media security? >>> Here the UA could find that it does media negotiation with >>> service-provider.net rather than with the end user >> (user@example.com). >>> It seems the lock item should not be displayed in this >> situation. Or >>> maybe the user could be consulted whether he/she accepts the >>> certificate of the intermediary even though it fails to >> identify the remote user. >>> Another situation is where a user is trying to contact >>> +123456789@example.com but gets back a From/Identity indicating >>> +123456789@service-provider.net and media is secured as far as >>> service-provider.net. Does this constitute grounds for >> displaying the icon? >>> John >>> >>>> -----Original Message----- >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: 29 October 2006 21:26 >>>> To: 'EKR'; 'David R Oran' >>>> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; 'Francois >>>> Audet'; 'Dean Willis' >>>> Subject: RE: [Sip] RE: TLS meaning >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Eric Rescorla [mailto:ekr@networkresonance.com] >>>>> Sent: Saturday, October 28, 2006 9:34 AM >>>>> >From a security perspective, SIPS has two important properties: >>>>> >>>>> 1. It says to the client "you MUST talk to me over SSL". >>>> I hope it doesn't say that. I thought we had to use TLS. ;) >>>> >>>> >>>>> 2. It says to the proxies "I expect you to make the outgoing >>>>> connection with TLS". >>>>> >>>>> As Samir has observed, the second property can be >> provided with some >>>>> indicator in the SIP header. However, the first can only >> be provided >>>>> by putting the indicator in the reference which you hand >>>> around (i.e., >>>>> the SIP URI). This isn't to say it necessarily has to be >> a new URI >>>>> scheme--though it did in HTTP because HTTP doesn't have >>>>> parameters--but it's not clear to me that moving it to parameters >>>>> would really help. >>>> I think the part some of us are worried about is it will >> inherit the >>>> perception of https: namely that the entire path from the >> caller to >>>> the answerer is secure. Just because an IETF doc says >> it's not the >>>> same, and says it's not a lock icon, will not overcome the >>>> perception. >>>> Even though an >>>> https connection is only secure to the TLS terminator (the >> server or >>>> an offloader), and the back-end from there is not, the >> assumption is >>>> the owner of the terminator takes on the responsibility from there >>>> (if there is any responsibility). And the terminator >> owner wanted to >>>> secure it between the browser and the terminator, and they >> got that. >>>> But SIP is neither HTTP nor SMTP. The sips uri may end at a pstn >>>> gateway, or an h323 IWF, or whatever. It may become sip later, as >>>> well. The owner of the TLS terminator does not >> necessarily equal the >>>> owner of the final UAS, nor the owner of the answerer. >> How can the >>>> owner of the terminator have any responsibility for something that >>>> may happen somewhere else, unbeknownst to him? How/why >> would someone >>>> who types in a sips uri for their request not think it's >> like https? >>>> In some ways the perception problem is exacerbated by the >> uri being >>>> the sips scheme. If it were a require/proxy-require instead, it >>>> would help alleviate that perception problem, IMO. But >> then you're >>>> left with trying such a request without the foreknowledge >> of success >>>> probability that a business-card sips address would give you. >>>> >>>> -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 >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 30 16:11:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeO7-0003dc-S0; Mon, 30 Oct 2006 16:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeO7-0003dU-2j for sip@ietf.org; Mon, 30 Oct 2006 16:09:43 -0500 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 1GeeO1-0008Pg-4Q for sip@ietf.org; Mon, 30 Oct 2006 16:09:43 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Y00F07W3ZCO@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Oct 2006 21:09:35 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG5KV8>; Mon, 30 Oct 2006 21:09:23 +0000 Content-return: allowed Date: Mon, 30 Oct 2006 21:09:17 +0000 From: "Elwell, John" To: Francois Audet , Paul Kyzivat Message-id: <50B1CBA96870A34799A506B2313F26670A3D780E@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: 65215b440f7ab00ca9514de4a7a89926 Cc: IETF SIP List Subject: [Sip] RE: What controls the lock icon? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, My feeling is that SIPS is certainly not sufficient for providing the padlock, and I am not even convinced it is relevant. So, notwithstanding the SIPS question, I was interested in people's opinion on the padlock. I agree that it is not the role of the IETF to specify the padlock. However, in practice many of our SIP devices will want to display a padlock or something similar, and it would be good to get some sort of consensus on the security mechanisms necessary to allow us to do that. Or to put it another way, a user will typically expect some sort of indication of whether what he says (audio) or what he shows (video) or what he types (IM) etc. will be sent securely to the entity he/she thinks is the remote party and likewise that such media, when received, have come from that remote party without modification en route. The user tends not to have a concept of signalling. So given these reasonable (IMO) expectations of the user, what signalling mechanisms would be necessary and sufficient to give the user this indication? As Paul says, I have changed the subject line. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 30 October 2006 20:03 > To: Paul Kyzivat; Elwell, John > Cc: IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > I really don't understand why people keep on bringing the > padlock thing > again in the context of sips. > > In a request-URI, sips is merely an indication that it is > requested that > all the hops (except possibly the last one) forward this request over > TLS. > RFC3261 uses a different URI scheme for that purpose as opposed to a > Require > header, but that's water under the bridge. That functionality > is useful. > > Many of us have explained over and over why being able to request that > a request be sent securely over TLS is useful. > > There is no implication of padlock icons here, neigher for > the sender or > > the receiver. > > There are many aspects to security, and it's not clear to me that the > role of IETF is to define the meaning of a padlock. Regardles, I can > think > of the following attribute: > > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? > > - Are selected parts of the SIP message itself and MIME bodies > (including SDP) > integrity protected end-to-end using SIP Identity (as per RFC 4474)? > > - Are the whole SIP message itself and MIME bodies (including SDP) > integrity > protected end-to-end using S/MIME (as per RFC 3993)? > > - Is media encrypted end-to-end using SRTP? > > - Is the key negotiation used for that secured end-to-end using > encryption (e.g., > MIKEY, SDESC with S/MIME). > > - Is the identity of the user sending the request secured with > sip-identity (RFC 4474)? > > - Are request mapped to a non-SIP network considered "secure" (e.g., > PSTN, H.323, etc.)? > > - Can we protect against B2BUA and the likes? > - etc. > > In short, there are many aspects to this, including (but not limited > to): > > - Authentication of users > > - Integrity protection > > - Encryption of signalling > > - Encryption of media > > - End-to-end versus hop-by-hop > > - Hop-of to another network (e.g., PSTN, H.323, etc.) > > - What cyphersuites are used > > - etc. > > It is not clear to me at all that we (SIP WG) can specify what the > padlock icon should be. > Different network deployment may wish to convey different > information to > end-users. > > In some deployment, you may want an indication that everything is > encrypted/authenticated > end-to-end (security, media, identity, etc.) using a > consolidated icon. > In other deployment, > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise > where lawful intercept > may be view as secure). > > In some other deployment, you amy want different padlock icons for > different security > properties. Or different levels of security. > > The point is, this is NOT SIPS. It's something else. If we decide to > tackle it or not > is another issue. I personally think it is a pretty tall > order, and I'm > not sure > it's the mandate of IETF. For now, I just want to ensure > that we don't > confuse > padlock with SIPS. > > > Cheers. > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, October 30, 2006 11:11 AM > > To: Elwell, John > > Cc: 'IETF SIP List' > > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: > > TLS meaning) > > > > I support John here. As stupid as it might seem, I think this > > little thing is likely to be very important. And figuring out > > what it takes to have it is a way at getting to underlying > > requirements for security in the protocol. Perhaps there are > > also other requirements for security, but at least this would > > provide one source. > > > > So far I have heard that having a SIPS connection doesn't > > imply that one can show this lock icon. What isn't yet clear > > to me is if that means that SIPS is a necessary but > > insufficient condition, or if SIPS is in fact not even > > helpful for providing it. I suspect it isn't even helpful. > > If not, then what *is* driving the requirements for SIPS? > > > > I think I would also extend John's proposal a bit. I think > > there *may* need to be different levels of security, where > > the lock icon corresponds to one of them. But this is a > > slippery slope, because if there are too many they become > > confusing to users. But too few of the wrong ones may not be > > useful in practice. > > > > For instance, it may be that there is a need for "PSTN quality" > > security. (I imagine that *ought* to be the same as "none", > > but in practice I think the PSTN level security is better > > than basic unsecured-sip-over-internet security, so knowing > > you had this when connected to the PSTN could be helpful.) > > But a "really secure" (better than PSTN) would be a great way > > of motivating deployment of IP-based e2e telephony services. > > > > Paul > > > > Elwell, John wrote: > > > Some of the discussion on the long thread on "TLS meaning" > > has led me > > > to seek opinions on what does indeed control the lock icon, > > since we > > > seem to have consensus that a successful SIPS request is > > not grounds > > > for showing the lock icon. > > > > > > The user surely will expect media to be secured end-to-end. By > > > end-to-end, I mean at least as far as the domain the user > believes > > > he/she is in communication with. So there has to be some > > cryptographic > > > assurance that the entity with which the UA agrees keys for media > > > security has the credentials of the entity indicated by caller or > > > connected party identity (From+Identity or possibly PAI). This is > > > probably a sufficient condition if key agreement is carried > > out using > > > D-H. If the key is transported, then an additional > > condition is that > > > the key is end-to-end encrypted, which for SDescriptions > > means encrypted using S/MIME. > > > > > > But what about the presence of B2BUAs, SBCs, etc. that do > > not have the > > > credentials of the end user but nevertheless terminate > > media security? > > > Here the UA could find that it does media negotiation with > > > service-provider.net rather than with the end user > > (user@example.com). > > > It seems the lock item should not be displayed in this > > situation. Or > > > maybe the user could be consulted whether he/she accepts the > > > certificate of the intermediary even though it fails to > > identify the remote user. > > > > > > Another situation is where a user is trying to contact > > > +123456789@example.com but gets back a From/Identity indicating > > > +123456789@service-provider.net and media is secured as far as > > > service-provider.net. Does this constitute grounds for > > displaying the icon? > > > > > > John > > > > > >> -----Original Message----- > > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > >> Sent: 29 October 2006 21:26 > > >> To: 'EKR'; 'David R Oran' > > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > 'Francois > > >> Audet'; 'Dean Willis' > > >> Subject: RE: [Sip] RE: TLS meaning > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > > >>> Sent: Saturday, October 28, 2006 9:34 AM > > >>> >From a security perspective, SIPS has two important properties: > > >>> > > >>> 1. It says to the client "you MUST talk to me over SSL". > > >> I hope it doesn't say that. I thought we had to use TLS. ;) > > >> > > >> > > >>> 2. It says to the proxies "I expect you to make the outgoing > > >>> connection with TLS". > > >>> > > >>> As Samir has observed, the second property can be > > provided with some > > >>> indicator in the SIP header. However, the first can only > > be provided > > >>> by putting the indicator in the reference which you hand > > >> around (i.e., > > >>> the SIP URI). This isn't to say it necessarily has to be > > a new URI > > >>> scheme--though it did in HTTP because HTTP doesn't have > > >>> parameters--but it's not clear to me that moving it to > parameters > > >>> would really help. > > >> I think the part some of us are worried about is it will > > inherit the > > >> perception of https: namely that the entire path from the > > caller to > > >> the answerer is secure. Just because an IETF doc says > > it's not the > > >> same, and says it's not a lock icon, will not overcome the > > >> perception. > > >> Even though an > > >> https connection is only secure to the TLS terminator (the > > server or > > >> an offloader), and the back-end from there is not, the > > assumption is > > >> the owner of the terminator takes on the responsibility > from there > > >> (if there is any responsibility). And the terminator > > owner wanted to > > >> secure it between the browser and the terminator, and they > > got that. > > >> > > >> But SIP is neither HTTP nor SMTP. The sips uri may end > at a pstn > > >> gateway, or an h323 IWF, or whatever. It may become sip > later, as > > >> well. The owner of the TLS terminator does not > > necessarily equal the > > >> owner of the final UAS, nor the owner of the answerer. > > How can the > > >> owner of the terminator have any responsibility for > something that > > >> may happen somewhere else, unbeknownst to him? How/why > > would someone > > >> who types in a sips uri for their request not think it's > > like https? > > >> > > >> In some ways the perception problem is exacerbated by the > > uri being > > >> the sips scheme. If it were a require/proxy-require instead, it > > >> would help alleviate that perception problem, IMO. But > > then you're > > >> left with trying such a request without the foreknowledge > > of success > > >> probability that a business-card sips address would give you. > > >> > > >> -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 > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 Oct 30 16:16:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeTB-0005Ia-T6; Mon, 30 Oct 2006 16:14:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeTA-0005HL-8B for sip@ietf.org; Mon, 30 Oct 2006 16:14:56 -0500 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 1GeeT8-0000WA-PI for sip@ietf.org; Mon, 30 Oct 2006 16:14:56 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Y00H02WD50M@siemenscomms.co.uk> for sip@ietf.org; Mon, 30 Oct 2006 21:15:05 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG5KX1>; Mon, 30 Oct 2006 21:14:53 +0000 Content-return: allowed Date: Mon, 30 Oct 2006 21:14:49 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: Paul Kyzivat , Francois Audet Message-id: <50B1CBA96870A34799A506B2313F26670A3D7810@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: 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 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 30 October 2006 20:55 > To: Francois Audet > Cc: Elwell, John; IETF SIP List > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > > > Francois Audet wrote: > > I really don't understand why people keep on bringing the > padlock thing > > again in the context of sips. > > The subject line was changed to protect the guilty (er - > innocent). :-) > > Seriously, while related its not exactly the same subject, so > don't take > it personally. > > > In a request-URI, sips is merely an indication that it is > requested that > > all the hops (except possibly the last one) forward this > request over > > TLS. > > RFC3261 uses a different URI scheme for that purpose as opposed to a > > Require > > header, but that's water under the bridge. That > functionality is useful. > > I think you have a good handle on having a clear definition > of what SIPS > means. IMO the question is, once that is settled, is how useful and > important that is. > > > Many of us have explained over and over why being able to > request that > > a request be sent securely over TLS is useful. > > Does it solve enough problems to be worth the trouble of > getting deployed? [JRE] That is the tenuous link between the new thread on the lock icon and the original thread on SIPS. I am not yet convinced that SIPS solves real world problems. I am not convinced that SIPS is a necessary condition for displaying the icon. > > > There is no implication of padlock icons here, neigher for > the sender or > > the receiver. > > > > There are many aspects to security, and it's not clear to > me that the > > role of IETF is to define the meaning of a padlock. Regardles, I can > > think of the following attribute: > > It may not be necessary for the ietf to define this, or at > least that it > make the one and only definition. But it could be important > to establish > a framework within which it is clear how to make such > definitions, and > perhaps to make one definition to serve as a proof of concept and to > help in understanding what dependencies there are on > mechanisms such as > SIPS. [JRE] I agree. > > > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? > > > > - Are selected parts of the SIP message itself and MIME bodies > > (including SDP) > > integrity protected end-to-end using SIP Identity (as per > RFC 4474)? > > > > - Are the whole SIP message itself and MIME bodies (including SDP) > > integrity > > protected end-to-end using S/MIME (as per RFC 3993)? > > > > - Is media encrypted end-to-end using SRTP? > > > > - Is the key negotiation used for that secured end-to-end using > > encryption (e.g., > > MIKEY, SDESC with S/MIME). > > > > - Is the identity of the user sending the request secured with > > sip-identity (RFC 4474)? > > > > - Are request mapped to a non-SIP network considered "secure" (e.g., > > PSTN, H.323, etc.)? > > > > - Can we protect against B2BUA and the likes? > > - etc. > > I think I agree with these, though it may turn out that in > practice all > aren't necessary. Getting an idea of what it means to > "protect against a > B2BUA" could be very interesting. > > > In short, there are many aspects to this, including (but not limited > > to): > > > > - Authentication of users > > > > - Integrity protection > > > > - Encryption of signalling > > > > - Encryption of media > > > > - End-to-end versus hop-by-hop > > > > - Hop-of to another network (e.g., PSTN, H.323, etc.) > > > > - What cyphersuites are used > > > > - etc. > > > > It is not clear to me at all that we (SIP WG) can specify what the > > padlock icon should be. > > Different network deployment may wish to convey different > information to > > end-users. > > That could lead to some nasty interoperability issues when > considering > "networks" that interconnect. Maybe it is inevitable that > there will be > limited or no real security in cases like this, but I think > there will > be demand for some. (For really disconnected networks, such as for > military command and control, interop probably isn't an issue and a > special definition would be appropriate.) > > > In some deployment, you may want an indication that everything is > > encrypted/authenticated > > end-to-end (security, media, identity, etc.) using a > consolidated icon. > > In other deployment, > > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise > > where lawful intercept > > may be view as secure). > > > > In some other deployment, you amy want different padlock icons for > > different security > > properties. Or different levels of security. > > > > The point is, this is NOT SIPS. It's something else. If we decide to > > tackle it or not > > is another issue. I personally think it is a pretty tall > order, and I'm > > not sure > > it's the mandate of IETF. For now, I just want to ensure > that we don't > > confuse > > padlock with SIPS. > > I agree it probably isn't within the current charter. And I > don't know > where it would fall in a priority list. But I think it is > something that > will eventually need to be done, and I don't see who other > than the ietf > would be appropriate to do a general framework that could support > interoperability over the internet. > > Paul > > > Cheers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 16:26:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeecI-0005aM-MV; Mon, 30 Oct 2006 16:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeecH-0005TA-5n for sip@ietf.org; Mon, 30 Oct 2006 16:24:21 -0500 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeecE-0001OI-O5 for sip@ietf.org; Mon, 30 Oct 2006 16:24:21 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id DA1B53BEA5; Mon, 30 Oct 2006 22:24:07 +0100 (CET) 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 10818-01-6; Mon, 30 Oct 2006 22:24:07 +0100 (CET) Received: from itft (c-4ff9e055.1161-1-64736c11.cust.bredbandsbolaget.se [85.224.249.79]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 730743BE22; Mon, 30 Oct 2006 22:24:07 +0100 (CET) Message-ID: <089801c6fc69$b57d2100$191e0bc1@it.su.se> From: "Fredrik Thulin" To: "Christer Holmberg \(JO/LMF\)" , References: <5EB80D22825EEE42872083AD5BFFB59404549211@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] One big concern with outbound-05 Date: Mon, 30 Oct 2006 22:23:55 +0100 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.2962 X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.564 tagged_above=-99 required=7 tests=[AWL=0.101, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) 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 Christer Holmberg (JO/LMF) wrote: > Hi, > > I don't think you can assume that the sip-p.net proxies won't add Path > headers. Path is used for other purposes than outbound, so there may > be many non-outbound related reasons why proxies add Path. > > For example, in IMS the P-CSCF could be the edge proxy, but then you > can have other intermediate nodes between the P-CSCF and home S-CSCF > (registrar) that insert Path. My concern was only with not having more proxys than necessary adding themselves to the Path vector. I do however see the problem you are talking about with Outbound effectively being disabled if there is some other proxy on the way between the UA and the registrar that adds itself to the Path vector for some non-Outbound reason, and not including the ;ob parameter since it doesn't know about Outbound. In that case, reachability from the Authoritative proxy / registrar to the UA won't be guaranteed. Changing it to what you suggest, only demand the edge proxy closest to the UA to support Outbound, would of course (at least slightly) reduce the chance of reachability from the Authoritative proxy / registrar to the UA, but at least until now I haven't been able to come to any other conclusion than that it would probably work often enough (because the edge proxys closest to the UA probably will have global reachability)... I am looking forward to Rohan's response to this. When thinking about this I came up with another question : What if there are NATs between a series of edge proxys between the UA and the Authoritative proxy / registrar - who is going to keep those connections alive? The UA will keep it's connection to the first edge proxy alive using STUN keepalives, but who is going to make sure that the flows between the edge proxys are still alive? /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 Oct 30 16:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeepK-0003UZ-DS; Mon, 30 Oct 2006 16:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeepI-0003SS-Qs for sip@ietf.org; Mon, 30 Oct 2006 16:37:48 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeepE-0003C9-58 for sip@ietf.org; Mon, 30 Oct 2006 16:37:48 -0500 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 k9ULUlB10286; Mon, 30 Oct 2006 16:30:47 -0500 (EST) 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] RE: What controls the lock icon? Date: Mon, 30 Oct 2006 15:37:33 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F567672@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D780E@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: What controls the lock icon? Thread-Index: Acb8Z9s9Dx3UBqcaQVGVhc4h5m3C3AAAv9jA From: "Samir Srivastava" To: "Elwell, John" , "Francois Audet" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 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 have yet to catch up the lengthy today's discussions. Let me ask a different question Can SIPS in it's current specified form play any role in controlling the lock icon for *SIGNALING ONLY* ? Then going for media, Key exchange, Bodies etc is just loosing the focus. Thx Samir PS : Two wacky threads, and 5 years of time with unclearness itself is sufficient evidence what we are hunting for ? > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, October 30, 2006 1:09 PM > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List > Subject: [Sip] RE: What controls the lock icon? >=20 > Francois, >=20 > My feeling is that SIPS is certainly not sufficient for providing the > padlock, and I am not even convinced it is relevant. So, notwithstanding > the > SIPS question, I was interested in people's opinion on the padlock. >=20 > I agree that it is not the role of the IETF to specify the padlock. > However, > in practice many of our SIP devices will want to display a padlock or > something similar, and it would be good to get some sort of consensus on > the > security mechanisms necessary to allow us to do that. Or to put it another > way, a user will typically expect some sort of indication of whether what > he > says (audio) or what he shows (video) or what he types (IM) etc. will be > sent securely to the entity he/she thinks is the remote party and likewise > that such media, when received, have come from that remote party without > modification en route. The user tends not to have a concept of signalling. > So given these reasonable (IMO) expectations of the user, what signalling > mechanisms would be necessary and sufficient to give the user this > indication? >=20 > As Paul says, I have changed the subject line. >=20 > John >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 30 October 2006 20:03 > > To: Paul Kyzivat; Elwell, John > > Cc: IETF SIP List > > Subject: RE: WhaFrom sip-bounces@ietf.org Mon Oct 30 16:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeepK-0003UZ-DS; Mon, 30 Oct 2006 16:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeepI-0003SS-Qs for sip@ietf.org; Mon, 30 Oct 2006 16:37:48 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeepE-0003C9-58 for sip@ietf.org; Mon, 30 Oct 2006 16:37:48 -0500 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 k9ULUlB10286; Mon, 30 Oct 2006 16:30:47 -0500 (EST) 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] RE: What controls the lock icon? Date: Mon, 30 Oct 2006 15:37:33 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F567672@zrc2hxm2.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D780E@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: What controls the lock icon? Thread-Index: Acb8Z9s9Dx3UBqcaQVGVhc4h5m3C3AAAv9jA From: "Samir Srivastava" To: "Elwell, John" , "Francois Audet" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 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 have yet to catch up the lengthy today's discussions. Let me ask a different question Can SIPS in it's current specified form play any role in controlling the lock icon for *SIGNALING ONLY* ? Then going for media, Key exchange, Bodies etc is just loosing the focus. Thx Samir PS : Two wacky threads, and 5 years of time with unclearness itself is sufficient evidence what we are hunting for ? > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: Monday, October 30, 2006 1:09 PM > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List > Subject: [Sip] RE: What controls the lock icon? >=20 > Francois, >=20 > My feeling is that SIPS is certainly not sufficient for providing the > padlock, and I am not even convinced it is relevant. So, notwithstanding > the > SIPS question, I was interested in people's opinion on the padlock. >=20 > I agree that it is not the role of the IETF to specify the padlock. > However, > in practice many of our SIP devices will want to display a padlock or > something similar, and it would be good to get some sort of consensus on > the > security mechanisms necessary to allow us to do that. Or to put it another > way, a user will typically expect some sort of indication of whether what > he > says (audio) or what he shows (video) or what he types (IM) etc. will be > sent securely to the entity he/she thinks is the remote party and likewise > that such media, when received, have come from that remote party without > modification en route. The user tends not to have a concept of signalling. > So given these reasonable (IMO) expectations of the user, what signalling > mechanisms would be necessary and sufficient to give the user this > indication? >=20 > As Paul says, I have changed the subject line. >=20 > John >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 30 October 2006 20:03 > > To: Paul Kyzivat; Elwell, John > > Cc: IETF SIP List > > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > > TLS meaning) > > > > I really don't understand why people keep on bringing the > > padlock thing > > again in the context of sips. > > > > In a request-URI, sips is merely an indication that it is > > requested that > > all the hops (except possibly the last one) forward this request over > > TLS. > > RFC3261 uses a different URI scheme for that purpose as opposed to a > > Require > > header, but that's water under the bridge. That functionality > > is useful. > > > > Many of us have explained over and over why being able to request that > > a request be sent securely over TLS is useful. > > > > There is no implication of padlock icons here, neigher for > > the sender or > > > > the receiver. > > > > There are many aspects to security, and it's not clear to me that the > > role of IETF is to define the meaning of a padlock. Regardles, I can > > think > > of the following attribute: > > > > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? > > > > - Are selected parts of the SIP message itself and MIME bodies > > (including SDP) > > integrity protected end-to-end using SIP Identity (as per RFC 4474)? > > > > - Are the whole SIP message itself and MIME bodies (including SDP) > > integrity > > protected end-to-end using S/MIME (as per RFC 3993)? > > > > - Is media encrypted end-to-end using SRTP? > > > > - Is the key negotiation used for that secured end-to-end using > > encryption (e.g., > > MIKEY, SDESC with S/MIME). > > > > - Is the identity of the user sending the request secured with > > sip-identity (RFC 4474)? > > > > - Are request mapped to a non-SIP network considered "secure" (e.g., > > PSTN, H.323, etc.)? > > > > - Can we protect against B2BUA and the likes? > > - etc. > > > > In short, there are many aspects to this, including (but not limited > > to): > > > > - Authentication of users > > > > - Integrity protection > > > > - Encryption of signalling > > > > - Encryption of media > > > > - End-to-end versus hop-by-hop > > > > - Hop-of to another network (e.g., PSTN, H.323, etc.) > > > > - What cyphersuites are used > > > > - etc. > > > > It is not clear to me at all that we (SIP WG) can specify what the > > padlock icon should be. > > Different network deployment may wish to convey different > > information to > > end-users. > > > > In some deployment, you may want an indication that everything is > > encrypted/authenticated > > end-to-end (security, media, identity, etc.) using a > > consolidated icon. > > In other deployment, > > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise > > where lawful intercept > > may be view as secure). > > > > In some other deployment, you amy want different padlock icons for > > different security > > properties. Or different levels of security. > > > > The point is, this is NOT SIPS. It's something else. If we decide to > > tackle it or not > > is another issue. I personally think it is a pretty tall > > order, and I'm > > not sure > > it's the mandate of IETF. For now, I just want to ensure > > that we don't > > confuse > > padlock with SIPS. > > > > > > Cheers. > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, October 30, 2006 11:11 AM > > > To: Elwell, John > > > Cc: 'IETF SIP List' > > > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: > > > TLS meaning) > > > > > > I support John here. As stupid as it might seem, I think this > > > little thing is likely to be very important. And figuring out > > > what it takes to have it is a way at getting to underlying > > > requirements for security in the protocol. Perhaps there are > > > also other requirements for security, but at least this would > > > provide one source. > > > > > > So far I have heard that having a SIPS connection doesn't > > > imply that one can show this lock icon. What isn't yet clear > > > to me is if that means that SIPS is a necessary but > > > insufficient condition, or if SIPS is in fact not even > > > helpful for providing it. I suspect controls the lock icon? (Was RE: [Sip] RE: > > TLS meaning) > > > > I really don't understand why people keep on bringing the > > padlock thing > > again in the context of sips. > > > > In a request-URI, sips is merely an indication that it is > > requested that > > all the hops (except possibly the last one) forward this request over > > TLS. > > RFC3261 uses a different URI scheme for that purpose as opposed to a > > Require > > header, but that's water under the bridge. That functionality > > is useful. > > > > Many of us have explained over and over why being able to request that > > a request be sent securely over TLS is useful. > > > > There is no implication of padlock icons here, neigher for > > the sender or > > > > the receiver. > > > > There are many aspects to security, and it's not clear to me that the > > role of IETF is to define the meaning of a padlock. Regardles, I can > > think > > of the following attribute: > > > > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? > > > > - Are selected parts of the SIP message itself and MIME bodies > > (including SDP) > > integrity protected end-to-end using SIP Identity (as per RFC 4474)? > > > > - Are the whole SIP message itself and MIME bodies (including SDP) > > integrity > > protected end-to-end using S/MIME (as per RFC 3993)? > > > > - Is media encrypted end-to-end using SRTP? > > > > - Is the key negotiation used for that secured end-to-end using > > encryption (e.g., > > MIKEY, SDESC with S/MIME). > > > > - Is the identity of the user sending the request secured with > > sip-identity (RFC 4474)? > > > > - Are request mapped to a non-SIP network considered "secure" (e.g., > > PSTN, H.323, etc.)? > > > > - Can we protect against B2BUA and the likes? > > - etc. > > > > In short, there are many aspects to this, including (but not limited > > to): > > > > - Authentication of users > > > > - Integrity protection > > > > - Encryption of signalling > > > > - Encryption of media > > > > - End-to-end versus hop-by-hop > > > > - Hop-of to another network (e.g., PSTN, H.323, etc.) > > > > - What cyphersuites are used > > > > - etc. > > > > It is not clear to me at all that we (SIP WG) can specify what the > > padlock icon should be. > > Different network deployment may wish to convey different > > information to > > end-users. > > > > In some deployment, you may want an indication that everything is > > encrypted/authenticated > > end-to-end (security, media, identity, etc.) using a > > consolidated icon. > > In other deployment, > > maybe hop-by-hop is the desired behavior (e.g., inside an enterprise > > where lawful intercept > > may be view as secure). > > > > In some other deployment, you amy want different padlock icons for > > different security > > properties. Or different levels of security. > > > > The point is, this is NOT SIPS. It's something else. If we decide to > > tackle it or not > > is another issue. I personally think it is a pretty tall > > order, and I'm > > not sure > > it's the mandate of IETF. For now, I just want to ensure > > that we don't > > confuse > > padlock with SIPS. > > > > > > Cheers. > > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Monday, October 30, 2006 11:11 AM > > > To: Elwell, John > > > Cc: 'IETF SIP List' > > > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: > > > TLS meaning) > > > > > > I support John here. As stupid as it might seem, I think this > > > little thing is likely to be very important. And figuring out > > > what it takes to have it is a way at getting to underlying > > > requirements for security in the protocol. Perhaps there are > > > also other requirements for security, but at least this would > > > provide one source. > > > > > > So far I have heard that having a SIPS connection doesn't > > > imply that one can show this lock icon. What isn't yet clear > > > to me is if that means that SIPS is a necessary but > > > insufficient condition, or if SIPS is in fact not even > > > helpful for providing it. I suspect it isn't even helpful. > > > If not, then what *is* driving the requirements for SIPS? > > > > > > I think I would also extend John's proposal a bit. I think > > > there *may* need to be different levels of security, where > > > the lock icon corresponds to one of them. But this is a > > > slippery slope, because if there are too many they become > > > confusing to users. But too few of the wrong ones may not be > > > useful in practice. > > > > > > For instance, it may be that there is a need for "PSTN quality" > > > security. (I imagine that *ought* to be the same as "none", > > > but in practice I think the PSTN level security is better > > > than basic unsecured-sip-over-internet security, so knowing > > > you had this when connected to the PSTN could be helpful.) > > > But a "really secure" (better than PSTN) would be a great way > > > of motivating deployment of IP-based e2e telephony services. > > > > > > Paul > > > > > > Elwell, John wrote: > > > > Some of the discussion on the long thread on "TLS meaning" > > > has led me > > > > to seek opinions on what does indeed control the lock icon, > > > since we > > > > seem to have consensus that a successful SIPS request is > > > not grounds > > > > for showing the lock icon. > > > > > > > > The user surely will expect media to be secured end-to-end. By > > > > end-to-end, I mean at least as far as the domain the user > > believes > > > > he/she is in communication with. So there has to be some > > > cryptographic > > > > assurance that the entity with which the UA agrees keys for media > > > > security has the credentials of the entity indicated by caller or > > > > connected party identity (From+Identity or possibly PAI). This is > > > > probably a sufficient condition if key agreement is carried > > > out using > > > > D-H. If the key is transported, then an additional > > > condition is that > > > > the key is end-to-end encrypted, which for SDescriptions > > > means encrypted using S/MIME. > > > > > > > > But what about the presence of B2BUAs, SBCs, etc. that do > > > not have the > > > > credentials of the end user but nevertheless terminate > > > media security? > > > > Here the UA could find that it does media negotiation with > > > > service-provider.net rather than with the end user > > > (user@example.com). > > > > It seems the lock item should not be displayed in this > > > situation. Or > > > > maybe the user could be consulted whether he/she accepts the > > > > certificate of the intermediary even though it fails to > > > identify the remote user. > > > > > > > > Another situation is where a user is trying to contact > > > > +123456789@example.com but gets back a From/Identity indicating > > > > +123456789@service-provider.net and media is secured as far as > > > > service-provider.net. Does this constitute grounds for > > > displaying the icon? > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > >> Sent: 29 October 2006 21:26 > > > >> To: 'EKR'; 'David R Oran' > > > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > > 'Francois > > > >> Audet'; 'Dean Willis' > > > >> Subject: RE: [Sip] RE: TLS meaning > > > >> > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > >>> Sent: Saturday, October 28, 2006 9:34 AM > > > >>> >From a security perspective, SIPS has two important properties: > > > >>> > > > >>> 1. It says to the client "you MUST talk to me over SSL". > > > >> I hope it doesn't say that. I thought we had to use TLS. ;) > > > >> > > > >> > > > >>> 2. It says to the proxies "I expect you to make the outgoing > > > >>> connection with TLS". > > > >>> > > > >>> As Samir has observed, the second property can be > > > provided with some > > > >>> indicator in the SIP header. However, the first can only > > > be provided > > > >>> by putting the indicator in the reference which you hand > > > >> around (i.e., > > > >>> the SIP URI). This isn't to say it necessarily has to be > > > a new URIt it isn't even helpful. > > > If not, then what *is* driving the requirements for SIPS? > > > > > > I think I would also extend John's proposal a bit. I think > > > there *may* need to be different levels of security, where > > > the lock icon corresponds to one of them. But this is a > > > slippery slope, because if there are too many they become > > > confusing to users. But too few of the wrong ones may not be > > > useful in practice. > > > > > > For instance, it may be that there is a need for "PSTN quality" > > > security. (I imagine that *ought* to be the same as "none", > > > but in practice I think the PSTN level security is better > > > than basic unsecured-sip-over-internet security, so knowing > > > you had this when connected to the PSTN could be helpful.) > > > But a "really secure" (better than PSTN) would be a great way > > > of motivating deployment of IP-based e2e telephony services. > > > > > > Paul > > > > > > Elwell, John wrote: > > > > Some of the discussion on the long thread on "TLS meaning" > > > has led me > > > > to seek opinions on what does indeed control the lock icon, > > > since we > > > > seem to have consensus that a successful SIPS request is > > > not grounds > > > > for showing the lock icon. > > > > > > > > The user surely will expect media to be secured end-to-end. By > > > > end-to-end, I mean at least as far as the domain the user > > believes > > > > he/she is in communication with. So there has to be some > > > cryptographic > > > > assurance that the entity with which the UA agrees keys for media > > > > security has the credentials of the entity indicated by caller or > > > > connected party identity (From+Identity or possibly PAI). This is > > > > probably a sufficient condition if key agreement is carried > > > out using > > > > D-H. If the key is transported, then an additional > > > condition is that > > > > the key is end-to-end encrypted, which for SDescriptions > > > means encrypted using S/MIME. > > > > > > > > But what about the presence of B2BUAs, SBCs, etc. that do > > > not have the > > > > credentials of the end user but nevertheless terminate > > > media security? > > > > Here the UA could find that it does media negotiation with > > > > service-provider.net rather than with the end user > > > (user@example.com). > > > > It seems the lock item should not be displayed in this > > > situation. Or > > > > maybe the user could be consulted whether he/she accepts the > > > > certificate of the intermediary even though it fails to > > > identify the remote user. > > > > > > > > Another situation is where a user is trying to contact > > > > +123456789@example.com but gets back a From/Identity indicating > > > > +123456789@service-provider.net and media is secured as far as > > > > service-provider.net. Does this constitute grounds for > > > displaying the icon? > > > > > > > > John > > > > > > > >> -----Original Message----- > > > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > > >> Sent: 29 October 2006 21:26 > > > >> To: 'EKR'; 'David R Oran' > > > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat'; > > 'Francois > > > >> Audet'; 'Dean Willis' > > > >> Subject: RE: [Sip] RE: TLS meaning > > > >> > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > > > >>> Sent: Saturday, October 28, 2006 9:34 AM > > > >>> >From a security perspective, SIPS has two important properties: > > > >>> > > > >>> 1. It says to the client "you MUST talk to me over SSL". > > > >> I hope it doesn't say that. I thought we had to use TLS. ;) > > > >> > > > >> > > > >>> 2. It says to the proxies "I expect you to make the outgoing > > > >>> connection with TLS". > > > >>> > > > >>> As Samir has observed, the second property can be > > > provided with some > > > >>> indicator in the SIP header. However, the first can only > > > be provided > > > >>> by putting the indicator in the reference which you hand > > > >> around (i.e., > > > >>> the SIP URI). This isn't to say it necessarily has to be > > > a new URI > > > >>> scheme--though it did in HTTP because HTTP doesn't have > > > >>> parameters--but it's not clear to me that moving it to > > parameters > > > >>> would really help. > > > >> I think the part some of us are worried about is it will > > > inherit the > > > >> perception of https: namely that the entire path from the > > > caller to > > > >> the answerer is secure. Just because an IETF doc says > > > it's not the > > > >> same, and says it's not a lock icon, will not overcome the > > > >> perception. > > > >> Even though an > > > >> https connection is only secure to the TLS terminator (the > > > server or > > > >> an offloader), and the back-end from there is not, the > > > assumption is > > > >> the owner of the terminator takes on the responsibility > > from there > > > >> (if there is any responsibility). And the terminator > > > owner wanted to > > > >> secure it between the browser and the terminator, and they > > > got that. > > > >> > > > >> But SIP is neither HTTP nor SMTP. The sips uri may end > > at a pstn > > > >> gateway, or an h323 IWF, or whatever. It may become sip > > later, as > > > >> well. The owner of the TLS terminator does not > > > necessarily equal the > > > >> owner of the final UAS, nor the owner of the answerer. > > > How can the > > > >> owner of the terminator have any responsibility for > > something that > > > >> may happen somewhere else, unbeknownst to him? How/why > > > would someone > > > >> who types in a sips uri for their request not think it's > > > like https? > > > >> > > > >> In some ways the perception problem is exacerbated by the > > > uri being > > > >> the sips scheme. If it were a require/proxy-require instead, it > > > >> would help alleviate that perception problem, IMO. But > > > then you're > > > >> left with trying such a request without the foreknowledge > > > of success > > > >> probability that a business-card sips address would give you. > > > >> > > > >> -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 > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 Mon Oct 30 16:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoM-0002tN-2i; Mon, 30 Oct 2006 16:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoK-0002s9-TA for sip@ietf.org; Mon, 30 Oct 2006 16:36:48 -0500 Received: from mailgw4.ericsson.se ([193.180 > > > >>> scheme--though it did in HTTP because HTTP doesn't have > > > >>> parameters--but it's not clear to me that moving it to > > parameters > > > >>> would really help. > > > >> I think the part some of us are worried about is it will > > > inherit the > > > >> perception of https: namely that the entire path from the > > > caller to > > > >> the answerer is secure. Just because an IETF doc says > > > it's not the > > > >> same, and says it's not a lock icon, will not overcome the > > > >> perception. > > > >> Even though an > > > >> https connection is only secure to the TLS terminator (the > > > server or > > > >> an offloader), and the back-end from there is not, the > > > assumption is > > > >> the owner of the terminator takes on the responsibility > > from there > > > >> (if there is any responsibility). And the terminator > > > owner wanted to > > > >> secure it between the browser and the terminator, and they > > > got that. > > > >> > > > >> But SIP is neither HTTP nor SMTP. The sips uri may end > > at a pstn > > > >> gateway, or an h323 IWF, or whatever. It may become sip > > later, as > > > >> well. The owner of the TLS terminator does not > > > necessarily equal the > > > >> owner of the final UAS, nor the owner of the answerer. > > > How can the > > > >> owner of the terminator have any responsibility for > > something that > > > >> may happen somewhere else, unbeknownst to him? How/why > > > would someone > > > >> who types in a sips uri for their request not think it's > > > like https? > > > >> > > > >> In some ways the perception problem is exacerbated by the > > > uri being > > > >> the sips scheme. If it were a require/proxy-require instead, it > > > >> would help alleviate that perception problem, IMO. But > > > then you're > > > >> left with trying such a request without the foreknowledge > > > of success > > > >> probability that a business-card sips address would give you. > > > >> > > > >> -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 > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP 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 Mon Oct 30 16:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoM-0002tN-2i; Mon, 30 Oct 2006 16:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoK-0002s9-TA for sip@ietf.org; Mon, 30 Oct 2006 16:36:48 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeoB-0002xI-Cm for sip@ietf.org; Mon, 30 Oct 2006 16:36:48 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A7CDF559; Mon, 30 Oct 2006 22:36:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 22:36:36 +0100 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] One big concern with outbound-05 Date: Mon, 30 Oct 2006 22:36:34 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045492C4@esealmw113.eemea.ericsson.se> In-Reply-To: <089801c6fc69$b57d2100$191e0bc1@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] One big concern with outbound-05 Thread-Index: Acb8abw2JPHZceGkQ/2L0jQZpyXZdwAAD/Yg From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , X-OriginalArrivalTime: 30 Oct 2006 21:36:36.0258 (UTC) FILETIME=[79D8A820:01C6FC6B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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,=20 >>I don't think you can assume that the sip-p.net proxies won't add Path >>headers. Path is used for other purposes than outbound, so=20 >>there may be many non-outbound related reasons why proxies add Path. >> >>For example, in IMS the P-CSCF could be the edge proxy, but=20 >>then you can have other intermediate nodes between the P-CSCF and home S-CSCF >>(registrar) that insert Path. >=20 >My concern was only with not having more proxys than=20 >necessary adding themselves to the Path vector. I understand. But, we can still not make any assumptions on that issue. For example, in an IMS roaming scenario you could have 3 entities adding a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a home IBCF. =20 >I do however see the problem you are talking about with=20 >Outbound effectively being disabled if there is some other=20 >proxy on the way between the UA and the registrar that adds=20 >itself to the Path vector for some non-Outbound reason, and=20 >not including the ;ob parameter since it doesn't know about=20 >Outbound. In that case, reachability from the Authoritative=20 >proxy / registrar to the UA won't be guaranteed. >=20 >Changing it to what you suggest, only demand the edge proxy=20 >closest to the UA to support Outbound, would of course (at=20 >least slightly) reduce the chance of reachability from the=20 >Authoritative proxy / registrar to the UA, but at least until=20 >now I haven't been able to come to any other conclusion than=20 >that it would probably work often enough (because the edge=20 >proxys closest to the UA probably will have global reachability)...=20 >I am looking forward to Rohan's response to this. =20 Me too :) >When thinking about this I came up with another question : >=20 >What if there are NATs between a series of edge proxys=20 >between the UA and the Authoritative proxy / registrar - who=20 >is going to keep those connections alive? The UA will keep=20 >it's connection to the first edge proxy alive using STUN=20 >keepalives, but who is going to make sure that the flows=20 >between the edge proxys are still alive? I think the assumption is that the non-controllable NAT(s) will only be located in the "access network", between the UA and the edge proxy. At least tha.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeoB-0002xI-Cm for sip@ietf.org; Mon, 30 Oct 2006 16:36:48 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A7CDF559; Mon, 30 Oct 2006 22:36:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 22:36:36 +0100 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] One big concern with outbound-05 Date: Mon, 30 Oct 2006 22:36:34 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045492C4@esealmw113.eemea.ericsson.se> In-Reply-To: <089801c6fc69$b57d2100$191e0bc1@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] One big concern with outbound-05 Thread-Index: Acb8abw2JPHZceGkQ/2L0jQZpyXZdwAAD/Yg From: "Christer Holmberg \(JO/LMF\)" To: "Fredrik Thulin" , X-OriginalArrivalTime: 30 Oct 2006 21:36:36.0258 (UTC) FILETIME=[79D8A820:01C6FC6B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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,=20 >>I don't think you can assume that the sip-p.net proxies won't add Path >>headers. Path is used for other purposes than outbound, so=20 >>there may be many non-outbound related reasons why proxies add Path. >> >>For example, in IMS the P-CSCF could be the edge proxy, but=20 >>then you can have other intermediate nodes between the P-CSCF and home S-CSCF >>(registrar) that insert Path. >=20 >My concern was only with not having more proxys than=20 >necessary adding themselves to the Path vector. I understand. But, we can still not make any assumptions on that issue. For example, in an IMS roaming scenario you could have 3 entities adding a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a home IBCF. =20 >I do however see the problem you are talking about with=20 >Outbound effectively being disabled if there is some other=20 >proxy on the way between the UA and the registrar that adds=20 >itself to the Path vector for some non-Outbound reason, and=20 >not including the ;ob parameter since it doesn't know about=20 >Outbound. In that case, reachability from the Authoritative=20 >proxy / registrar to the UA won't be guaranteed. >=20 >Changing it to what you suggest, only demand the edge proxy=20 >closest to the UA to support Outbound, would of course (at=20 >least slightly) reduce the chance of reachability from the=20 >Authoritative proxy / registrar to the UA, but at least until=20 >now I haven't been able to come to any other conclusion than=20 >that it would probably work often enough (because the edge=20 >proxys closest to the UA probably will have global reachability)...=20 >I am looking forward to Rohan's response to this. =20 Me too :) >When thinking about this I came up with another question : >=20 >What if there are NATs between a series of edge proxys=20 >between the UA and the Authoritative proxy / registrar - who=20 >is going to keep those connections alive? The UA will keep=20 >it's connection to the first edge proxy alive using STUN=20 >keepalives, but who is going to make sure that the flows=20 >between the edge proxys are still alive? I think the assumption is that the non-controllable NAT(s) will only be located in the "access network", between the UA and the edge proxy. At least that is the assumption in IMS. I am not sure I understand the concept of multiple edge proxies in the flow path, but that is a separate issue... 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 t is the assumption in IMS. I am not sure I understand the concept of multiple edge proxies in the flow path, but that is a separate issue... 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 Oct 30 16:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7f-00025H-ES; Mon, 30 Oct 2006 16:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7e-00024u-9J for sip@ietf.org; Mon, 30 Oct 2006 16:56:46 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gef7Z-0005Qy-RL for sip@ietf.org; Mon, 30 Oct 2006 16:56:46 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gef7Y-0004E8-Ni for sip@ietf.org; Mon, 30 Oct 2006 16:56:41 -0500 Message-Id: <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 30 Oct 2006 16:54:48 -0500 To: "'IETF SIP List'" From: "Joel M. Halpern" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112032ec25108862fb4a4db290d52edf19ce7b0702bda879915d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) 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 The question is what "some other ... mechanisms are appropriate" means. Presumably, if SIPS means something useful (either TLS end to almost end, or some other definition) our hope would be to teach users that if they want security they should use SIPS. If we are going to teach them that, and we are going to restrict SIPS to TLS, then what does it mean to say that "some other hop by hop security mechanisms are appropriate?" Does it mean that other measures are appropriate if the user didn't ask for security? Does it mean that we should make up another hop-wise secure URI schema (I hope not.) The users don't care about what actual protocol is used to provide the security. And if they understand at all what a proxy is, and that there can be intermediate proxies, then they presumably don't care which intermediate proxies are in the path. They presumably care that proxies do their job right, but that seems to me to be a proxy issue, not an end user issue. And proving that the "right" thing happened is clearly a very different problem, with its own complications. Let me turn this around and ask the opposite stupid question. What breaks if we say 1) Every UAC and every proxy SHOULD utilize security on its requests to the next hop for all requests. 2) Every proxy must support TLS. Every UAC must be able to invoke TLS. (Already required I believe.) 3) Other mechanisms with equivalent security properties may be used instead of TLS to meet (1). Then you don;t need SIPS. And there is no downgrade attack. I will acknowledge that a) this is not what 3261 says b) that the equivalence in 3 is complex, and may open the door to some folks making bad choices. But we already leave that door open in other regards. The best solution is to be clear about what the security properties are. Probably there is some obvious and simple reason the above is a bad idea. But this way it is no longer hammering at my skull for release. Yours, Joel M. Halpern At 02:26 PM 10/30/2006, Brian Rosen wrote: >I think the distinFrom sip-bounces@ietf.org Mon Oct 30 16:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7f-00025H-ES; Mon, 30 Oct 2006 16:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7e-00024u-9J for sip@ietf.org; Mon, 30 Oct 2006 16:56:46 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gef7Z-0005Qy-RL for sip@ietf.org; Mon, 30 Oct 2006 16:56:46 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gef7Y-0004E8-Ni for sip@ietf.org; Mon, 30 Oct 2006 16:56:41 -0500 Message-Id: <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 30 Oct 2006 16:54:48 -0500 To: "'IETF SIP List'" From: "Joel M. Halpern" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112032ec25108862fb4a4db290d52edf19ce7b0702bda879915d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) 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 The question is what "some other ... mechanisms are appropriate" means. Presumably, if SIPS means something useful (either TLS end to almost end, or some other definition) our hope would be to teach users that if they want security they should use SIPS. If we are going to teach them that, and we are going to restrict SIPS to TLS, then what does it mean to say that "some other hop by hop security mechanisms are appropriate?" Does it mean that other measures are appropriate if the user didn't ask for security? Does it mean that we should make up another hop-wise secure URI schema (I hope not.) The users don't care about what actual protocol is used to provide the security. And if they understand at all what a proxy is, and that there can be intermediate proxies, then they presumably don't care which intermediate proxies are in the path. They presumably care that proxies do their job right, but that seems to me to be a proxy issue, not an end user issue. And proving that the "right" thing happened is clearly a very different problem, with its own complications. Let me turn this around and ask the opposite stupid question. What breaks if we say 1) Every UAC and every proxy SHOULD utilize security on its requests to the next hop for all requests. 2) Every proxy must support TLS. Every UAC must be able to invoke TLS. (Already required I believe.) 3) Other mechanisms with equivalent security properties may be used instead of TLS to meet (1). Then you don;t need SIPS. And there is no downgrade attack. I will acknowledge that a) this is not what 3261 says b) that the equivalence in 3 is complex, and may open the door to some folks making bad choices. But we already leave that door open in other regards. The best solution is to be clear about what the security properties are. Probably there is some obvious and simple reason the above is a bad idea. But this way it is no longer hammering at my skull for release. Yours, Joel M. Halpern At 02:26 PM 10/30/2006, Brian Rosen wrote: >I think the distinction some of us are making is that while we agree that >some other hop by hop security mechanisms are appropriate, and those >mechanisms would use different mechanisms than all-TLS, sips meaning all TLS >is useful, and deployable, and we should clarify 3261 to achieve that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 16:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef8W-0002PW-Mx; Mon, 30 Oct 2006 16:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7m-00029t-UO for sip@ietf.org; Mon, 30 Oct 2006 16:56:55 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gef12-0004T5-Gq for sip@ietf.org; Mon, 30 Oct 2006 16:50:00 -0500 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 k9ULnrs06459 for ; Mon, 30 Oct 2006 16:49:53 -0500 (EST) 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] RE: What controls the lock icon? Date: Mon, 30 Oct 2006 15:49:51 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC98C4E@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F567672@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: What controls the lock icon? Thread-Index: Acb8Z9s9Dx3UBqcaQVGVhc4h5m3C3AAAv9jAAACDQwA= From: "Francois Audet" To: "Samir Srivastava" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 =20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Monday, October 30, 2006 1:38 PM > To: Elwell, John; Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List > Subject: RE: [Sip] RE: What controls the lock icon? >=20 > I have yet to catch up the lengthy today's discussions. >=20 > Let me ask a different question Can SIPS in it's current=20 > specified form play any role in controlling the lock icon for=20 > *SIGNALING ONLY* ? Then going for media, Key exchange, Bodies=20 > etc is just loosing the focus. Answer is NO.=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 ction some of us are making is that while we agree that >some other hop by hop security mechanisms are appropriate, and those >mechanisms would use different mechanisms than all-TLS, sips meaning all TLS >is useful, and deployable, and we should clarify 3261 to achieve that. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 16:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef8W-0002PW-Mx; Mon, 30 Oct 2006 16:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef7m-00029t-UO for sip@ietf.org; Mon, 30 Oct 2006 16:56:55 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gef12-0004T5-Gq for sip@ietf.org; Mon, 30 Oct 2006 16:50:00 -0500 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 k9ULnrs06459 for ; Mon, 30 Oct 2006 16:49:53 -0500 (EST) 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] RE: What controls the lock icon? Date: Mon, 30 Oct 2006 15:49:51 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC98C4E@zrc2hxm0.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60F567672@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: What controls the lock icon? Thread-Index: Acb8Z9s9Dx3UBqcaQVGVhc4h5m3C3AAAv9jAAACDQwA= From: "Francois Audet" To: "Samir Srivastava" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 =20 > -----Original Message----- > From: Srivastava, Samir (SC100:8826)=20 > Sent: Monday, October 30, 2006 1:38 PM > To: Elwell, John; Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List > Subject: RE: [Sip] RE: What controls the lock icon? >=20 > I have yet to catch up the lengthy today's discussions. >=20 > Let me ask a different question Can SIPS in it's current=20 > specified form play any role in controlling the lock icon for=20 > *SIGNALING ONLY* ? Then going for media, Key exchange, Bodies=20 > etc is just loosing the focus. Answer is NO.=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 Oct 30 16:59:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef8u-0002cG-0O; Mon, 30 Oct 2006 16:58:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gef81-0002Hj-F9; Mon, 30 Oct 2006 16:57:09 -0500 Received: from aopmgw4.andrew.com ([198.17.217.205] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geeuo-0003p8-83; Mon, 30 Oct 2006 16:43:34 -0500 X-SEF-Processed: 5_0_0_910__2006_10_30_15_42_30 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from Unknown [10.3.20.66] by aopmgw4 - SurfControl E-mail Filter (5.2.1); Mon, 30 Oct 2006 15:42:27 -0600 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Oct 2006 15:43:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-05.txt Date: Mon, 30 Oct 2006 15:43:22 -0600 Message-ID: In-Reply-To: <4.3.2.7.2.20061030113259.02542550@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Sip] I-DACTION:draft-ietf-sip-location-conveyance-05.txt Thread-Index: Acb8SsNF6e4TMtO2SMyb+dGzUV4doQAIUXUg From: "Thomson, Martin" To: "James M. Polk" , X-OriginalArrivalTime: 30 Oct 2006 21:43:23.0949 (UTC) FILETIME=[6CD95DD0:01C6FC6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: geopriv@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="===============0598125128==" Errors-To: sip-bounces@ietf.org --===============0598125128== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoaWNoIGV4dHJhIHRhZyB5b3UgYXJlIHJlZmVy cmluZyB0bw0KDQpUaGUgUElERi1MTyB0YWcgInJvdXRpbmctcXVlcnktYWxsb3dlZCIgd2FzIGlu IHRoZSAtMDQgZHJhZnQgKG5vdGUgdGhlIGRhdGUgb24gbXkgZW1haWwgOikuICBPYnZpb3VzbHks IG15IGNvbW1lbnRzIGRvbid0IGFwcGx5IHRvIHRoZSAtMDUgZHJhZnQ7IHRoYW5rIHlvdS4NCg0K TQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphbWVzIE0uIFBvbGsg W21haWx0bzpqbXBvbGtAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCAzMSBPY3RvYmVyIDIw MDYgNDo0MSBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluOyBKZXJvZW4gdmFuIEJlbW1lbDsgc2lw QGlldGYub3JnDQo+IENjOiBnZW9wcml2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbR2VvcHJp dl0gUmU6IFtTaXBdIEktREFDVElPTjpkcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi0NCj4gY29udmV5 YW5jZS0wNS50eHQNCj4gDQo+IEF0IDA2OjU0IFBNIDEwLzIyLzIwMDYgLTA1MDAsIFRob21zb24s IE1hcnRpbiB3cm90ZToNCj4gPkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsNCj4gPiAgICAgICAg IGNoYXJzZXQ9InV0Zi04Ig0KPiA+Q29udGVudC1jbGFzczogdXJuOmNvbnRlbnQtY2xhc3Nlczpt ZXNzYWdlDQo+ID4NCj4gPlRoZSBleHRyYSBQSURGLUxPIHRhZyBpcyB0aGUgb25seSBmZWF0dXJl IG9mIHRoZSBkcmFmdCB0aGF0IEkgaGF2ZSBhDQo+ID5wcm9ibGVtIHdpdGguDQo+IA0KPiBNYXJ0 aW4NCj4gDQo+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hpY2ggZXh0cmEgdGFnIHlvdSBh cmUgcmVmZXJyaW5nIHRvDQo+IA0KPiA+ICBUaGlzIHNlZW1zIGxpa2UgYSBjYXNlIHdoZXJlIHRo ZSBsZXR0ZXIgb2YgdGhlIGxhdyBpcyB0YWtlbiBvdmVyIHRoZQ0KPiA+IHNwaXJpdCBvZiB0aGUg bGF3Lg0KPiA+DQo+ID5JIGFncmVlIHdpdGggSmVyb2VuIGluIHRoYXQgYSBTSVAgcHJveHkgc2hv dWxkIG5vdCBoYXZlIHRvIGNoYW5nZSBpdHMNCj4gPmJlaGF2aW91ci4gIFdoYXQgd291bGQgYmUg bW9yZSBzZW5zaWJsZSBpcyB0byBhY2tub3dsZWRnZSB0aGF0IGEgU0lQDQo+ID5tZXNzYWdlIHdp dGggYW4gdW5lbmNyeXB0ZWQgYm9keSBjYW4gYmUgc2VlbiBieSBhbGwgcHJveGllcy4NCj4gDQo+ IEkgdGhpbmsgdGhpcyBpcyBvYnZpb3VzIGJ5IHRoaXMgaW4gdGhlIGRyYWZ0DQo+IA0KPiAgICAg ICAgSGVhZGVyIGZpZWxkICAgICAgICAgICAgIHdoZXJlIHByb3h5IElOViBBQ0sgQ0FOIEJZRSBS RUcgT1BUIFBSQQ0KPiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgR2VvbG9jYXRpb24gICAgICAg ICAgICAgIFJyICAgIGFyICAgICBvICAgLSAgIC0gICBvICAgbyAgIG8gICAtDQo+IA0KPiAgICAg ICAgSGVhZGVyIGZpZWxkICAgICAgICAgICAgIHdoZXJlIHByb3h5IFNVQiBOT1QgVVBEIE1TRyBS RUYgSU5GIFBVQg0KPiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgR2VvbG9jYXRpb24gICAgICAg ICAgICAgIFJyICAgIGFyICAgICBvICAgbyAgIG8gICBvICAgbyAgIG8gICAtDQo+IA0KPiAgICAg ICAgICAgICAgICAgVGFibGUgMTogU3VtbWFyeSBvZiB0aGUgR2VvbG9jYXRpb24gSGVhZGVyDQo+ IA0KPiB3aGVyZSBpdCBjbGVhcmx5IHN0YXRlcyB0aGUgcHJveHkgY2FuIHJlYWQgdGhlIG1lc3Nh Z2UgYm9keS4NCj4gDQo+IA0KPiA+QnkgaW5jbHVkaW5nIGEgUElERi1MTyBpbiB0aGlzIHdheSwg eW91IF9pbXBsaWNpdGx5XyBnaXZlIHByb3hpZXMNCj4gPnBlcm1pc3Npb24gdG8gZm9yd2FyZCBp dC4gIFlvdSBkb24ndCBuZWVkIHNwZWNpYWwgdGFncyBmb3IgdGhhdC4gIFRoYXQNCj4gPmNvdmVy cyB0aGUgbGFyZ2UgbnVtYmVyIG9mIHByb3hpZXMgdGhhdCBkb24ndCBjYXJlLCB0aGF0IGhhdmVu J3QgYmVlbg0KPiA+dXBncmFkZWQsIG9yIHRoYXQgd2lsbCBub3QgYmUgdXBncmFkZWQuDQo+ID4N Cj4gPkkgYWxzbyBkb24ndCBsaWtlIHRoZSBpZGVhIHRoYXQgdGhpcyB1cGRhdGVzIFJGQyA0MTE5 IHdpdGhvdXQgc2F5aW5nIGl0Lg0KPiANCj4gTXkgY28tYXV0aG9yIHNudWNrIGluIGEgUkZDNDEx OSB1cGRhdGUgaW4gLTA0LCB3aGljaCB3YXMgcmVtb3ZlZCBpbg0KPiAtMDUuICBDYW4geW91IHRl bGwgbWUgd2hlcmUgZWxzZSB5b3UgdGhpbmsgdGhpcyBJRCBvZmZpY2lhbGx5IChvciBob3cgeW91 DQo+IHJlYWQgaWYgc2hvdWxkIGJlIG9mZmljaWFsbHkpIHVwZGF0ZXMgNDExOT8NCj4gDQo+IEN1 cnJlbnRseSwgSSB0aGluayAtMDUgb2YgdGhpcyBkb2Mgb25seSB1cGRhdGVzIFJGQzMzMjYgd2l0 aCBhIG5ldyBSZWFzb24NCj4gcHJvdG9jb2wuDQo+IA0KPiBUaGVyZSBoYXMgYmVlbiBtZW50aW9u IG9mIHRha2luZyB0aGUgTG9jYXRpb24gRXJyb3IgQ29kZSBSZWdpc3RyeSBJRCBhbmQNCj4gaW5j b3Jwb3JhdGluZyBpdCBpbnRvIHRoaXMgQ29udmV5YW5jZSBJRCwgd2hpY2ggd2lsbCBhZGQgdG8g dGhpcyB1cGRhdGUgb2YNCj4gMzMyNi4NCj4gDQo+IA0KPiA+fg0KPiA+TWFydGluDQo+ID4NCj4g PiogTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSAicm91dGluZy1xdWVyeS1hbGxvd2VkIiB0 YWcgb25seSBhcHBsaWVzDQo+IHRvDQo+ID5ieS12YWx1ZTsgYSBieS1yZWZlcmVuY2UgVVJJIGNh biBiZSBmb3J3YXJkZWQgd2l0aG91dCBjb25jZXJucyoqLg0KPiA+DQo+ID4qKiBUaGVyZSBhcmUg bm93IGNhc2VzIHdoZXJlIHRoaXMgbWF5IG5vIGxvbmdlciBiZSB0cnVlLi4uIEZGUy4NCj4gPg0K PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEplcm9lbiB2YW4g QmVtbWVsIFttYWlsdG86amJlbW1lbEB6b25uZXQubmxdDQo+ID4gPiBTZW50OiBGcmlkYXksIDIw IE9jdG9iZXIgMjAwNiA0OjM4IFBNDQo+ID4gPiBUbzogc2lwQGlldGYub3JnDQo+ID4gPiBDYzog Z2VvcHJpdkBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogW0dlb3ByaXZdIFJlOiBbU2lwXSBJLURB Q1RJT046ZHJhZnQtaWV0Zi1zaXAtbG9jYXRpb24tDQo+IGNvbnZleWFuY2UtDQo+ID4gPiAwNS50 eHQNCj4gPiA+DQo+ID4gPiAiVGhlIGVudGl0aWVzIHJlY2VpdmluZyBsb2NhdGlvbiBNVVNUIG9i ZXkgdGhlIHByaXZhY3kgYW5kIHNlY3VyaXR5DQo+IHJ1bGVzDQo+ID4gPiBpbg0KPiA+ID4gdGhl IFBJREYtTE8gYXMgZGVzY3JpYmVkIGluIFJGQzQxMTksIHJlZ2FyZGluZyByZXRyYW5zbWlzc2lv biBhbmQNCj4gPiA+IHJldGVudGlvbi4iDQo+ID4gPg0KPiA+ID4gRG9lcyB0aGlzIG1lYW4gdGhh dCBhIFNJUCBwcm94eSByZWNlaXZpbmcgYSByZXF1ZXN0IHdpdGggYSBHZW9sb2NhdGlvbg0KPiA+ ID4gbXVzdA0KPiA+ID4gZmlyc3QgaW5zcGVjdCB0aGUgbG9jYXRpb24gb2JqZWN0IGJlZm9yZSBm b3J3YXJkaW5nPyBGb3INCj4gPiA+IGxvY2F0aW9uLWJ5LXJlZmVyZW5jZSwgdGhpcyBtYXkgaW50 cm9kdWNlIGFuIHVuYWNjZXB0YWJsZSBkZWxheSwNCj4gPiA+IGVzcGVjaWFsbHkNCj4gPiA+IHdo ZW4gdGhlIHByb3h5IGRvZXMgbm90IGRvIGFueXRoaW5nIHdpdGggdGhlIGxvY2F0aW9uIGluZm9y bWF0aW9uDQo+IGl0c2VsZi4NCj4gPiA+DQo+ID4gPiBQcm94aWVzIHRoYXQgZG9uJ3QgdW5kZXJz dGFuZCBHZW9sb2NhdGlvbiB3aWxsIGZvcndhcmQgYXMgdXN1YWwsDQo+IHBvc3NpYmx5DQo+ID4g PiB2aW9sYXRpbmcgdGhlIGZvcndhcmRpbmcgcG9saWN5LiBZb3UgbWF5IHdhbnQgdG8gc3BlbmQg c29tZSB3b3JkcyBvbg0KPiB0aGlzLg0KPiA+ID4gRm9yIHByb3hpZXMgdGhhdCBkbyB1bmRlcnN0 YW5kLCB5b3UgY291bGQgY29uc2lkZXIgaW5zZXJ0aW5nIGEgZmxhZyBpbg0KPiBhDQo+ID4gPiBT SVANCj4gPiA+IEdlb2xvY2F0aW9uIGhlYWRlciBmb3IgdGhlIGJ5LXJlZmVyZW5jZSBjYXNlLCBz dWNoIHRoYXQgYSBkZXJlZmVyZW5jZQ0KPiBpcw0KPiA+ID4gbm90DQo+ID4gPiBuZWVkZWQgdG8g b2J0YWluIHRoZSBwb2xpY3kNCj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4gSmVyb2VuDQo+ ID4gPg0KPiA+ID4gSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+ID4gPj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzDQo+ID4gPiA+PiBkaXJlY3Rvcmllcy4NCj4gPiA+ID4+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbA0KPiBXb3JraW5nDQo+ ID4gPiA+PiBHcm91cCBvZiB0aGUgSUVURi4NCj4gPiA+ID4+DQo+ID4gPiA+PiBUaXRsZSA6IFNl c3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCBMb2NhdGlvbiBDb252ZXlhbmNlDQo+ID4gPiA+PiBB dXRob3IocykgOiBKLiBQb2xrLCBCLiBSb3Nlbg0KPiA+ID4gPj4gRmlsZW5hbWUgOiBkcmFmdC1p ZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNlLTA1LnR4dA0KPiA+ID4gPj4gUGFnZXMgOiAyNg0K PiA+ID4gPj4gRGF0ZSA6IDIwMDYtMTAtMTkNCj4gPiA+ID4+DQo+ID4gPiA+PiBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NCj4gPiA+ ID4+ICAgUHJvdG9jb2wgKFNJUCkgdG8gY29udmV5IGdlb2dyYXBoaWMgbG9jYXRpb24gaW5mb3Jt YXRpb24gZnJvbSBvbmUNCj4gPiA+ID4+ICAgU0lQIGVudGl0eSB0byBhbm90aGVyIFNJUCBlbnRp dHkuICBUaGUgZXh0ZW5zaW9uIGNvdmVycyBlbmQgdG8NCj4gZW5kDQo+ID4gPiA+PiAgIGNvbnZl eWFuY2UgYXMgd2VsbCBhcyBsb2NhdGlvbi1iYXNlZCByb3V0aW5nLCB3aGVyZSBwcm94eSBzZXJ2 ZXJzDQo+ID4gPiA+PiAgIG1ha2Ugcm91dGluZyBkZWNpc2lvbnMgYmFzZWQgb24gdGhlIGxvY2F0 aW9uIG9mIHRoZSBVQUMuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJu ZXQtRHJhZnQgaXM6DQo+ID4gPiA+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi0NCj4gY29udmV5YW5jZS0NCj4gPiA+IDA1LnR4dA0K PiA+ID4gPj4NCj4gPiA+ID4+IFRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJLUQgQW5ub3Vu Y2VtZW50IGxpc3QsIHNlbmQgYSBtZXNzYWdlDQo+IHRvDQo+ID4gPiA+PiBpLWQtYW5ub3VuY2Ut cmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5DQo+ ID4gPiA+PiBvZg0KPiA+ID4gPj4gdGhlIG1lc3NhZ2UuDQo+ID4gPiA+PiBZb3UgY2FuIGFsc28g dmlzaXQNCj4gPiA+ID4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0kt RC1hbm5vdW5jZQ0KPiA+ID4gPj4gdG8gY2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNldHRpbmdz Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUC4gTG9naW4gd2l0aCB0aGUNCj4gPiA+ID4+IHVzZXJuYW1lICJhbm9u eW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVyDQo+ID4g PiA+PiBsb2dnaW5nIGluLCB0eXBlICJjZCBpbnRlcm5ldC1kcmFmdHMiIGFuZCB0aGVuDQo+ID4g PiA+PiAiZ2V0IGRyYWZ0LWlldGYtc2lwLWxvY2F0aW9uLWNvbnZleWFuY2UtMDUudHh0Ii4NCj4g PiA+ID4+DQo+ID4gPiA+PiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNh biBiZSBmb3VuZCBpbg0KPiA+ID4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0K PiA+ID4gPj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4g PiA+ID4+DQo+ID4gPiA+PiBJbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkg ZS1tYWlsLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFNlbmQgYSBtZXNzYWdlIHRvOg0KPiA+ID4gPj4g bWFpbHNlcnZAaWV0Zi5vcmcuDQo+ID4gPiA+PiBJbiB0aGUgYm9keSB0eXBlOg0KPiA+ID4gPj4g IkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNpcC1sb2NhdGlvbi1jb252ZXlhbmNl LTA1LnR4dCIuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gTk9URTogVGhlIG1haWwgc2VydmVyIGF0IGll dGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluDQo+ID4gPiA+PiBNSU1FLWVuY29kZWQg Zm9ybSBieSB1c2luZyB0aGUgIm1wYWNrIiB1dGlsaXR5LiAgVG8gdXNlIHRoaXMNCj4gPiA+ID4+ IGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRoZSAi RklMRSINCj4gPiA+ID4+IGNvbW1hbmQuICBUbyBkZWNvZGUgdGhlIHJlc3BvbnNlKHMpLCB5b3Ug d2lsbCBuZWVkICJtdW5wYWNrIiBvcg0KPiA+ID4gPj4gYSBNSU1FLWNvbXBsaWFudCBtYWlsIHJl YWRlci4gIERpZmZlcmVudCBNSU1FLWNvbXBsaWFudCBtYWlsDQo+IHJlYWRlcnMNCj4gPiA+ID4+ IGV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRo DQo+ID4gPiA+PiAibXVsdGlwYXJ0IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRvY3VtZW50cyB3aGlj aCBoYXZlIGJlZW4gc3BsaXQNCj4gPiA+ID4+IHVwIGludG8gbXVsdGlwbGUgbWVzc2FnZXMpLCBz byBjaGVjayB5b3VyIGxvY2FsIGRvY3VtZW50YXRpb24gb24NCj4gPiA+ID4+IGhvdyB0byBtYW5p cHVsYXRlIHRoZXNlIG1lc3NhZ2VzLg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJlbG93IGlzIHRoZSBk YXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXINCj4gPiA+ ID4+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZl cnNpb24gb2YgdGhlDQo+ID4gPiA+PiBJbnRlcm5ldC1EcmFmdC4NCj4gPiA+ID4+DQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPj4gU2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwDQo+ID4gPiA+PiBUaGlzIGxpc3QgaXMg Zm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4gPiA+ID4+IFVz ZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9uIGN1cnJl bnQgc2lwDQo+ID4gPiA+PiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRldmVsb3BtZW50 cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBHZW9wcml2IG1h aWxpbmcgbGlzdA0KPiA+ID4gR2VvcHJpdkBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KPiA+DQo+ID4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID5UaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBk ZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4gPmNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLg0KPiA+SWYgeW91 IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+ aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVz ZSBvZg0KPiA+dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KPiA+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+W21mX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPkdlb3ByaXYgbWFpbGluZyBsaXN0DQo+ID5HZW9w cml2QGlldGYub3JnDQo+ID5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9n ZW9wcml2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBt ZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250 YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1h dGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5h dXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============0598125128== 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 --===============0598125128==-- From sip-bounces@ietf.org Mon Oct 30 17:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefBZ-0004qu-Hx; Mon, 30 Oct 2006 17:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefBY-0004qn-82 for sip@ietf.org; Mon, 30 Oct 2006 17:00:48 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefBO-0006yf-WB for sip@ietf.org; Mon, 30 Oct 2006 17:00:48 -0500 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 k9UM0Yj27574; Mon, 30 Oct 2006 17:00:34 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 16:00:14 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC98C8E@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D7810@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8aHWHqeMjJXizTya1qssSQVtENwABUkdw From: "Francois Audet" To: "Elwell, John" , "Paul Kyzivat" 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 BTW: I read both Paul and John's email, and I'm broadly in agreement. See below for the SIPS linkage.=20 > > Does it solve enough problems to be worth the trouble of getting=20 > > deployed? > [JRE] That is the tenuous link between the new thread on the=20 > lock icon and the original thread on SIPS. I am not yet=20 > convinced that SIPS solves real world problems.=20 My response: As per my previous email, as well as numerous ones from others, SIPS's role is to=20 indicate that a request must be forwarded over TLS by all hops (with the unfortunate exception of the last one). This does solve a real and immediate real world problem for which there is no other solution today. If and when we define some other more enlightened mechanism (that supports other security mechanism than TLS, that doesn't have the last-hop hole, that is=20 truly end-to-end, etc.), then sure, we could deprecate sips, or just not use it. But that is some ways ahead and highly speculative at this point. There are people today that are strugling with implementing TLS and SIPS with=20 RFC 3261. That's what we are fixing in the short term. > I am not=20 > convinced that SIPS is a necessary condition for displaying the icon. Correct. In fact, I would say that those are totally different topics. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 19:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geh0V-0003ZK-ME; Mon, 30 Oct 2006 18:57:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geh0U-0003ZE-At for sip@ietf.org; Mon, 30 Oct 2006 18:57:30 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geh0Q-00029y-0R for sip@ietf.org; Mon, 30 Oct 2006 18:57:30 -0500 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 k9UNvEs16302; Mon, 30 Oct 2006 18:57:15 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 17:57:14 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F56799D@zrc2hxm2.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC98C8E@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8aHWHqeMjJXizTya1qssSQVtENwABUkdwAAQRjfA= From: "Samir Srivastava" To: "Francois Audet" , "Elwell, John" , "Paul Kyzivat" 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 > My response: >=20 > As per my previous email, as well as numerous ones from others, SIPS's > role is to > indicate that a request must be forwarded over TLS by all hops (with the > unfortunate > exception of the last one). This does solve a real and immediate real > world problem > for which there is no other solution today. >=20 > If and when we define some other more enlightened mechanism (that > supports other > security mechanism than TLS, that doesn't have the last-hop hole, that > is > truly end-to-end, etc.), then sure, we could deprecate sips, or just not > use it. But > that is some ways ahead and highly speculative at this point. >=20 > There are people today that are strugling with implementing TLS and SIPS > with > RFC 3261. That's what we are fixing in the short term. My concern is, If SIPS (in current form with RECOMMENDED strengths etc) gets *DEPLOYED*, then we are INVITING the nightmare of interworking issues with more elegant solutions (Proxy-Require/Require) already on the table. I cannot say it more loudly.=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 Oct 30 20:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GehxQ-0001ZB-0i; Mon, 30 Oct 2006 19:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GehxO-0001XP-Jt for sip@ietf.org; Mon, 30 Oct 2006 19:58:22 -0500 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 1GehxL-000343-7i for sip@ietf.org; Mon, 30 Oct 2006 19:58:21 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2006 16:58:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9V0wIP2002884; Mon, 30 Oct 2006 16:58:18 -0800 Received: from dwingwxp ([10.32.130.99]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9V0wIin020566; Mon, 30 Oct 2006 16:58:18 -0800 (PST) From: "Dan Wing" To: "'Brian Rosen'" , "'Joel M. Halpern'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 16:58:18 -0800 Message-ID: <57ae01c6fc87$a77190a0$5b82200a@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 In-Reply-To: <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> Thread-Index: Acb8VDmSXYzxDt7AQk+GWI+9WZk5mwAAi3ygAAwk/lA= DKIM-Signature: a=rsa-sha1; q=dns; l=4980; t=1162256298; x=1163120298; c=relaxed/simple; s=sjdkim1002; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning); X=v=3Dcisco.com=3B=20h=3DfBjQs5atTOqkoFVo8KGpdxHrZi0=3D; b=bf1tv0Tm0nj8bkYrcHxywgvk4jZAcRSDvFuso9HfDdQceVCkJu4B8G8l0rWqe5iqLtxoKRvI AGK8ViyZjZHtTS5pfr3CUoO0yPISsMCgdrNxAlA6dsv38fmoCFfh4ge+; Authentication-Results: sj-dkim-1.cisco.com; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 want sips to mean: we have protected the signaling by TLS > from one end > through each and every entity to the other end, with the > caveat that we only > have transitive trust in each leg that they are meeting this > requirement. > > With that in mind, I think defining the B2BUA as a hop, but > not the last hop > is the correct interpretation. Similarly, if one end is on > the PSTN, then > you don't have TLS from end to end. According to RFC3261, I do -- the SIP endpoint is that PSTN gateway. With your argument, that PSTN gateway would have to reject the SIPS call setup attempt, the originator would have to send it via SIP, and possibly expose their signaling and media to IP-based eavesdroppers (RFC4568 requires using SIPS or S/MIME to protect the key in SDP), just because the last hop was the PSTN. We lack a mechanism for the PSTN gateway to say "it's secured up to me, and I'm the last hop and I can't make the PSTN do SIPS, sorry." We only have a mechanism for the PSTN gateway to say "I can't do SIPS". > However, if you went from SIP to H.323, but it was hop > by hop TLS protected all along the path, than sips is > appropriate. H.323 has a SIPS-like mechanism to ensure all of the hops within H.323 are using TLS, including a PSTN gateway? -d > I think the distinction some of us are making is that while > we agree that some other hop by hop security mechanisms > are appropriate, and those mechanisms would use different > mechanisms than all-TLS, sips meaning all TLS > is useful, and deployable, and we should clarify 3261 to > achieve that. > > I think all of us in that position also take the position that doing > something else, beyond clarifying sips, is useful, and should > be done, but > should be called something other than sips. That is a lot > more work. I > don't hear any voices saying just clarify sips as TLS end to > end with no > further work. > > I hear some people disagreeing that sips meaning TLS end to > end is useful. > Some of those people want to simply deprecate sips and define > something > else. Others want to redefine sips to be something else. > The something > else is the same something else I want. > > I think we all tend to be agreeing on what that something > else should look > like: it should describe desired security properties, it > should allow any > suitable mechanism to achieve that goal, it should involve some use of > Require/Supported. > > Brian > > > -----Original Message----- > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > Sent: Monday, October 30, 2006 1:46 PM > > To: 'IETF SIP List' > > Subject: RE: What controls the lock icon? (Was RE: [Sip] > RE: TLS meaning) > > > > I have removed most of the attribution below because the question of > > who said it, or what exactly he said, is not my point at the moment. > > > > At 01:22 PM 10/30/2006, Someone wrote: > > >Okay, let's tackle some of these issues. > > > > > >I think in order to be useful: > > >sips: means .... > > > > > >Nothing else makes sense to me. > > > > Having had several off line discussions with people who know their > > stuff very well about this SIPS issue, what has become very clear to > > me is that different participants have very different mental models > > of the relative roles and responsibilities of the proxies and the > > initiating / terminating UAs in the SIP exchanges. And different > > understandings of what the expressed user desire is when > they say "sips:". > > > > This then results in people saying "nothing else makes sense to me." > > In fact, I still am having trouble understanding some of the points > > of view, because of this model conflict. (And I will readily admit > > that my mental model of what's going on may be wrong. But I can't > > seem to get to another one.) > > > > We then end up talking past each other. > > > > Yours, > > Joel M. Halpern > > > > PS: I am deliberately being a bit vague on the model mismatches for > > two reasons. Firstly, I think there are many more mismatches than > > just the ones between me and my correspondents. Secondly, I really > > don't want to mischaracterise other people's arguments. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 Oct 30 20:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiEV-0006Pp-GK; Mon, 30 Oct 2006 20:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiET-0006Pe-T4 for sip@ietf.org; Mon, 30 Oct 2006 20:16:01 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiES-0006MR-Fv for sip@ietf.org; Mon, 30 Oct 2006 20:16:01 -0500 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 k9V1Fuo29225 for ; Mon, 30 Oct 2006 20:15:56 -0500 (EST) 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] RE: TLS meaning Date: Mon, 30 Oct 2006 19:15:53 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F567A38@zrc2hxm2.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918069B44B@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: TLS meaning Thread-Index: Acb533uPfmQvNZF1QUGxueY9lB6XiQAAkU/gAF+HWyAASB9O4A== From: "Samir Srivastava" To: "Drage, Keith \(Keith\)" , "Francois Audet" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 Thx Keith.=20 With due respect to chairs decision, I dissented at the meeting minutes itself. I who suggested the Proxy-Require/Require was told in the ad-hoc meeting that there is already consensus on the SIPS and it is not even on the agenda to discuss. I was not the part of the meeting where that discussion was done. BTW, I am eagerly waiting for the contents requested in 3.C ) .=20 Thx Samir > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Sunday, October 29, 2006 3:50 PM > To: Audet, Francois (SC100:3055); IETF SIP List > Subject: RE: [Sip] RE: TLS meaning >=20 > As WG chair: >=20 > Please bear in mind: >=20 > 1) The WG agreed at the last meeting that the scope of this > document is an informational document. The minutes clearly state this, > and the charter as follows: >=20 > Mar 2007 Guidelines for use of SIP security to WGLC (Informational) >=20 > Jun 2007 Guidelines for use of SIP security to IESG (Informational) >=20 > Was updated to say this. (Both these have been presented to the mailing > list without comment in reasonable time so this as far as I am concerned > is a decision. Therefore this document in itself does not deprecate > SIPS, and we will need to decide to do this later. >=20 > 2) This document does not update RFC 3261 it itself. Francois > please update your abstract because this is not what this document does. > You may also want to investigate the RFC 2119 language as a result. > There will have to be other documents that update RFC3261 that are not > this document. Note that we did agree that this document was the basis > of this work, and therefore it should be reissued as a -00 SIP WG > document. >=20 > 3) What this document is/was intended to do was: >=20 > - clearly document what we had now, i.e. identify what occurred if > the user attempted xyd, and what level of security they did get if they > attempted xyz. >=20 > - identify what improvements or changes to our current SIP > security, as defined in RFC 3261, where therefore required. These could > fall into the following: >=20 > A) creation of new mechanisms that provided a level of security > that is not provided by the existing mechanisms. I this case we need to > clearly identify the improvement and motivate why it is needed. >=20 > B) changes to existing mechanisms to make them work. In this case, > we need to clearly state why the existing mechanism is broken, i.e. not > interoperable to produce a deterministic result. >=20 > C) deprecation of existing mechanism - the one we seem to be > discussing here. In this case, I (and we are the ones that have to > justify this to the IESG) want to understand firstly why the existing > mechanism is harmful to implementations if it continues to exist, and > also understand the impact on the existing implementation community if > we do deprecate. Therefore what this discussion must do is identify > these reasons and put them in the document. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 27 October 2006 17:12 > > To: IETF SIP List > > Subject: RE: [Sip] RE: TLS meaning > > > > In case people having noticed, it is looking like we are > > having a mailing list hum on the following 2 questions: > > > > 1 - Do you favour deprecating the sips scheme altogether (yes/no) > > > > 2 - Do you favour getting rid of the last-hop-exception rule (yes/no) > > > > > > Note: Voting Yes on 2 does not necessarily imply you are > > voting No on 1, but it will only make sense if sips is not deprecated. > > > > I'm keeping track of the vote. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 ecbfcf@carmeldigital.com Mon Oct 30 20:35:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeiXR-0001kj-Aq for sip-archive@lists.ietf.org; Mon, 30 Oct 2006 20:35:37 -0500 Received: from [196.218.137.67] (helo=host-196.218.67.137.tedata.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeiXP-0001gx-Lp for sip-archive@lists.ietf.org; Mon, 30 Oct 2006 20:35:37 -0500 From: "Mollie Brantley" To: Subject: necessary Watch out for this one Date: Tue, 31 2002 23:23:38 -0120 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 3.3 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 and because as a clerk his duties necessitated his calling at otherthey could not enter into the natural tendency to be happy and joyouscurious about stocks and bonds and he learned that some stocks and bonds Please read this letter attentively. Tailor AquaPonics is going to grow! It will icrease up to 70% Company: TAILOR AQUAPONICS Stock symbol: TQWW.PK Current price: 0.07$ Expected price: 0.26$ Check this inside news. It will be published on MARKETWIRE on the 1st of November 2006 Recent news: TQWW.PK is going to conquer the US market. They’re coming to America!!! Tailor AquaPonics recently announced plans to expand its operational facilities to the United States. The Nevada-based corporation with operations in Australia recently decided to translate its track record of success to the American market. Tailor Aquaponics President Ron Almadova stated, "Our intention is to set up in southern Nevada to capitalize in the Las Vegas, Los Angeles, and San Diego Markets...There are more persons in that triangle than in the whole Australia. Now that we have the board approval, we have pinpointed several possible locations that would serve our delivery profile." After the publishig of that news TQWW.PK will grow constantly for 3-4 weeks. Buy it now cause it is still cheap and you can enter almost for free. About Tailor AquaPonics Worldwide: Tailor AquaPonics Worldwide, Inc. owns a controlling interest in the international growth and development rights to Tailor Made Fish Farms, a company that has developed a technology-driven, easy to operate, land-based modular fish production system. This cutting-edge system is both sustainable and environmentally responsible in keeping with the spirit of maintaining an environmentally safe and friendly solution while producing high volumes of superior and healthier farmed fish. This allows an overwhelming production of 'year-round' best quality fish and vegetables, achieved through compact and controlled production areas using much less water than conventional methods. Our technique conserves water, is environmentally responsible, fresh health products and provides two crops from a single water uptake. P.S Rumor has it that 2 Million shares have already been sold that are NOT accounted for in DTC, if your familar with this term it is called a "SHORT SQUEEZE". We will be mailing TQWW.PK for the next 3 weeks and the price will icrease. It is your unique chance to double or triple your funds next week. they could not enter into the natural tendency to be happy and joyousmight be called a comfortable and happy family existence. Buttonwoodend of the business. He wanted to know where all the types of money came From sip-bounces@ietf.org Mon Oct 30 21:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GejU1-0004or-W9; Mon, 30 Oct 2006 21:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GejU0-0004ok-Nz for sip@ietf.org; Mon, 30 Oct 2006 21:36:08 -0500 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 1GejTz-0004Zz-6M for sip@ietf.org; Mon, 30 Oct 2006 21:36:08 -0500 Received: from hkaplan [24.54.31.12] by acmepacket.com with ESMTP (SMTPD-9.10) id A68E069C; Mon, 30 Oct 2006 21:35:58 -0500 From: "Hadriel Kaplan" To: "'Brian Rosen'" , "'Elwell, John'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 21:35:38 -0500 Message-ID: <000301c6fc95$40dc8bc0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb7/wvPhKOiqNqmQFKYt6HsHqH6AwANDxEgABfI1SA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) 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 I'm not sure that's tenable. When the request reaches the PSTN gateway, it reached the UAS. It would be practically impossible to define otherwise. What would an IAD/MTA do, if it received a SIPS request but would be ringing a POTS/FXS interface in the house? What if that IAD were physically in the CO? What would a PBX do, key-system, etc. Or even if it stayed IP - what would a SIP-to-Skype inter-working gateway do, or an enterprise system that controlled phones with skinny/unistim/whatever. What would it mean if the UAS used H.248 or MGCP to control media gateways while sending the "signaling" securely using sigtrans over TLS? SIPS asked for SIP over TLS. When it reached the SIPS UAS, it got it. -hadriel > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, October 30, 2006 1:23 PM > > I think in order to be useful: > sips: means yes you must carry TLS through B2BUAs and anything else that > could create an unsecure link > sips: means fail if you terminate on a gateway that interworks to a non > TLS > supported protocol, and the gateway must carry TLS through a protocol that > supports TLS. > > Nothing else makes sense to me. > > For B2BUAs and SBCs and other things, I think there is a simple test: if > the > ciphersuite included encryption, is the signaling encrypted end to end? > > For gateways, I think talking about interworking to non TLS secured > protocols is not what I want the sips success to mean. It's not a secure > TLS hop by hop end to end. This is especially true if the gateway is to > the > PSTN. It does mean that a gateway that interworked to, say H.323 could > succeed with sips if it was possible to determine that the H.323 signaling > was TLS protected all the way. > > 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 Mon Oct 30 21:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GejmF-0000qY-Rl; Mon, 30 Oct 2006 21:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GejmD-0000qM-Q4 for sip@ietf.org; Mon, 30 Oct 2006 21:54:57 -0500 Received: from s-utl02-dcpop.stsn.net ([72.255.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GejmC-0008MA-J6 for sip@ietf.org; Mon, 30 Oct 2006 21:54:57 -0500 Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006103021545229501 ; Mon, 30 Oct 2006 21:54:52 -0500 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,BAYES_00: -1.665,SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from BROSENLT40xp ([10.33.171.141]) by s-utl02-dcpop.stsn.net; Mon, 30 Oct 2006 21:54:50 -0500 From: "Brian Rosen" To: "'Dan Wing'" , "'Joel M. Halpern'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Mon, 30 Oct 2006 21:54:35 -0500 Message-ID: <000501c6fc97$eebdb870$d529fea9@cis.neustar.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 In-Reply-To: <57ae01c6fc87$a77190a0$5b82200a@amer.cisco.com> Thread-Index: Acb8VDmSXYzxDt7AQk+GWI+9WZk5mwAAi3ygAAwk/lAAAiF1kA== 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 > > is the correct interpretation. Similarly, if one end is on > > the PSTN, then > > you don't have TLS from end to end. > > According to RFC3261, I do -- the SIP endpoint is that PSTN > gateway. > > With your argument, that PSTN gateway would have to reject > the SIPS call setup attempt, the originator would have to > send it via SIP, and possibly expose their signaling and > media to IP-based eavesdroppers (RFC4568 requires using > SIPS or S/MIME to protect the key in SDP), just because > the last hop was the PSTN. Yes, I agree that's what you would have to do, which would be the same circumstance if the first hop, which may very well be in a domain that you can trust can't handle TLS. This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful. I think we need to be fairly practical, and I also think we need to think about what it means to the system as a whole, and not JUST the UAC to UAS connection. If the signaling is not protected end to end, then it's not "protected" and saying that a piece of it is protected is not interesting to anyone. You might as well say that there was at least one hop which was protected. I feel that the PSTN is not protected signaling via TLS, and that's what sips means to me. I think that is a useful mechanism, if it really means TLS end to end. I don't think it's very useful if all it means is one arc of UAC to UAS if the actual call has two or three such arcs joined by B2BUAs, or one end is a PSTN connection. There may be some yet to be defined security mechanism that allows a more nuanced expression of what is acceptable, and what was accomplished, but that's not sips, at least in my opinion. > > We lack a mechanism for the PSTN gateway to say "it's > secured up to me, and I'm the last hop and I can't > make the PSTN do SIPS, sorry." We only have a > mechanism for the PSTN gateway to say "I can't do SIPS". Yes, I agree, but that is just the same, to me, as a proxy that can't do TLS downstream, or a B2BUA that can't do TLS downstream. I don't care WHY they can't maintain secure signaling connections via TLS end to end, I just know they can't. That's what I want to know; my signaling is protected end to end via a hop by hop TLS mechanism. 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 Mon Oct 30 23:19:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gel1k-0005BG-7u; Mon, 30 Oct 2006 23:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gel1i-0005B5-Df for sip@ietf.org; Mon, 30 Oct 2006 23:15:02 -0500 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gel1f-0004eU-PJ for sip@ietf.org; Mon, 30 Oct 2006 23:15:02 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B2A1D205FF for ; Tue, 31 Oct 2006 09:39:33 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9F2C5205E1 for ; Tue, 31 Oct 2006 09:39:33 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.162]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:44: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Date: Tue, 31 Oct 2006 09:44:52 +0530 Message-ID: <8A24F115EA58164490CD026E9D0CEAD4AB015D@BLR-EC-MBX02.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Thread-Index: Acb735DO2hLdDQoLSyisDLk4w7jBbgABPjwwAC9h5DA= From: To: X-OriginalArrivalTime: 31 Oct 2006 04:14:53.0743 (UTC) FILETIME=[1DDB7BF0:01C6FCA3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Fwding the mail to the list. I did a reply , should have done reply all. Thanks Dale for pointing this. -Sreeram. -----Original Message----- From: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks)=20 Sent: Monday, October 30, 2006 11:21 AM To: 'Dale.Worley@comcast.net' Subject: RE: [Sip] Draft for review:draft-sreeram-specify-method-00.txt Hi Dale, There are 2 Cases Proxy with backup: Means there is inactive unit. Which will take over when the active proxy is taken out (Duplex) Proxy without backup: These are proxies which work as stand-alone. Proxies to be stand alone are generally very rare in field but can be possible. When we say a Proxy with out backup giving the alternative ip address is the case when standalone proxy (P1) is giving the details of proxy P2 . The use cases have shown some of these cases. We will take care that the sentence is reformatted in the next release to make it clear. Regards, Sreeram -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 Sent: Monday, October 30, 2006 10:19 AM To: sip@ietf.org Subject: Re: [Sip] Draft for review:draft-sreeram-specify-method-00.txt You write: Similarly, on restart/disconnect of a SIP entity without backup, the same problem exists and there is no way by which SIP entity that is restarting/disconnecting can inform about the alternative IP address (if available) to other SIP entities to which it can communicate so that graceful handling of existing sessions (or calls) or future sessions can be performed using alternate IP address. I don't understand what the "alternate IP address" can be -- you've already said the SIP entity does not have a backup, so there can be no alternate IP address at which to contact the backup. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 30 23:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GelKp-0000Xx-9q; Mon, 30 Oct 2006 23:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GelKn-0000X7-07 for sip@ietf.org; Mon, 30 Oct 2006 23:34:45 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GelKf-0007gl-E1 for sip@ietf.org; Mon, 30 Oct 2006 23:34:44 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E10C18EB; Tue, 31 Oct 2006 05:33:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 05:33:50 +0100 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, 31 Oct 2006 05:33:45 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB59404549344@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Outbound-05: Editorial comments Thread-Index: Acb8pcCtJ6yEJ1HvQ5y5cPPNHVms6g== From: "Christer Holmberg \(JO/LMF\)" To: X-OriginalArrivalTime: 31 Oct 2006 04:33:50.0032 (UTC) FILETIME=[C3236D00:01C6FCA5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Rohan Mahy Subject: [Sip] Outbound-05: Editorial 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 Hi, Some editorial comments on outbound-05: Abstract: --------- Instead of: "It also defines keep alive behaviors needed to keep NAT bindings open" ...I propose that we should say something like: "It also defines how SIP implements the STUN keepalive usage [reference]" Introduction: ------------- Instead of: "The key idea of this specification" ...I propose that we should say something like: "The key idea of the outbound mechanism defined in this specification" Because, the are two key ideas in the spec: the outbound mechanism and the STUN keepalive for SIP. Instead of: "This mechanism also uses a keep alive mechanism over each flow so that the UA can detect when a flow has failed." ...I propose that we should say something like: "This specification also defines how SIP implements the STUN keepalive usage. The keepalive mechanism is used by outbound to keep NAT bindings, and to allow the UA to detect when a flow has failed. The keepalive mechanism can also be used as a stand-alone function, or together with other SIP extensions". Chapter 3.5: ------------ Instead of: "This specification describes using STUN [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP traffic to perform the keepalive." ...I propose that we should say something like: "This specification describes the usage of the STUN keepalive usage [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP traffic to perform the keepalive. The SIP implementation of the STUN keepalive usage is described in chapter 8 of this specification." Chapter 8: ---------- In generel I think this chapter is good, but I don't think we should talk about "flows" here, becuase the chapter is not part of outbound itself (I also still strongly think that we should define a flag which can be inserted in Path/Service-Route, but that issue is discussed in another thread). So, I think it would be enough to say something like: "The STUN messages can be used to verify that connectivity is still available, and to provide periodic keepalives in order to keep NAT bindings open. ...and: "A SIP node MUST NOT send STUN requests unless it has an explicit indication that the target next hop SIP server claims to support STUN."=20 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 Tue Oct 31 00:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemMD-00057x-N7; Tue, 31 Oct 2006 00:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemMC-00057T-Fh for sip@ietf.org; Tue, 31 Oct 2006 00:40:16 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GemGz-0006aJ-Kh for sip@ietf.org; Tue, 31 Oct 2006 00:34:56 -0500 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9V5Yo604282; Mon, 30 Oct 2006 22:34:50 -0700 Message-ID: <4546E074.6080203@ntt-at.com> Date: Mon, 30 Oct 2006 21:34:44 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeff Hodges References: <453DD1C4.7080005@neustar.biz> In-Reply-To: <453DD1C4.7080005@neustar.biz> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: IETF SIP List Subject: [Sip] Re: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeff; I saw the change in text below but the text following the changed text concerns me a bit which may need to be changed as well. ## Text from RFC4474 page 14 ########## "HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 [10], and for those URIs the indicated resource MUST be of the form 'application/pkix-cert'" It reads like resource indicated by either HTTP or HTTPS has to be a certificate, not something containing the certificate. Or I am reading the text above incorrectly. Regards Shida Jeff Hodges wrote: > Tschofenig, Hannes wrote: > > > >> * I'm not clear on how this mechanism works with older sip-identity > >> implementations. The main issue is whether the URI in the > identity-info > >> header field will return just a certificate, as specified in > sip-identity, > >> or whether it returns a saml assertion. An older sip-identity verifier > >> will expect a certificate but it will get an assertion if the AS > >> implements sip-saml. Perhaps you are assuming that the Accept > headers or > >> something are used for this? Somehow this needs to be handled. > > > > My understanding was that this got fixed with the SIP Identity draft. I > > might, however, be worth to double-check it. > > I double-checked it, and I think we perhaps have an issue here. > > I see that the language of interest has now changed from (bottom of > page 14 > in -sip-identity-06).. > > The 'absoluteURI' portion of the Identity-Info header MUST contain > either an HTTP or HTTPS URI which dereferences to a resource that > contains a single MIME body containing the certificate of the > authentication service. These URIs MUST follow the conventions of > RFC2585 [10] and the indicated resource MUST be of the form > 'application/pkix-cert' described in that specification. ... > > ..to this at the beginning of the second para of page 15 (in RFC4474).. > > The 'absoluteURI' portion of the Identity-Info header MUST contain a > URI which dereferences to a resource containing the certificate of > the authentication service. All implementations of this > specification MUST support the use of HTTP and HTTPS URIs in the > Identity-Info header. Such HTTP and HTTPS URIs MUST follow the > conventions of RFC 2585 [10], and for those URIs the indicated > resource MUST be of the form 'application/pkix-cert' described in > that specification. ... > > > Given the revised text above, I'm a tad concerned that implementors will > interpret the 3d sentence to mean that their implementations need _only_ > support HTTP/HTTPS URIs pointing to certificates as described in > RFC2585, even > though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs > pointing at resources other than certificates and/or CRL files are > allowable, > as long as the resource resolves one way or another into a > "..certificate of > the authentication service" (1st sentence above) -- as in a URI > pointing to a > SAML assertion containing such a cert. > > thoughts? > > thanks, > > =JeffH > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 31 01:51:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenPq-0002W2-QU; Tue, 31 Oct 2006 01:48:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenPo-0002Vw-5u for sip@ietf.org; Tue, 31 Oct 2006 01:48:04 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GenPk-00012V-GW for sip@ietf.org; Tue, 31 Oct 2006 01:48:04 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k9V6lhFR020022; Tue, 31 Oct 2006 07:47:44 +0100 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 k9V6lhXT026233; Tue, 31 Oct 2006 07:47:43 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 07:47:32 +0100 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 07:46:22 +0100 Message-ID: In-Reply-To: <57ae01c6fc87$a77190a0$5b82200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8VDmSXYzxDt7AQk+GWI+9WZk5mwAAi3ygAAwk/lAAC+GuYA== From: "Fries, Steffen" To: "Dan Wing" , "Brian Rosen" , "Joel M. Halpern" , "IETF SIP List" X-OriginalArrivalTime: 31 Oct 2006 06:47:32.0779 (UTC) FILETIME=[711177B0:01C6FCB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 > H.323 has a SIPS-like mechanism to ensure all of the hops=20 > within H.323 are using TLS, including a PSTN gateway? No, H.323 hasn't. H.323 supports using TLS to protect the call signaling, which you can apply in a proxy like model or in a direct call model. When you use an extra channel for call control, you can negotiate to use TLS as protection meachnism via the call signaling channel, but this is noly related for the next hop. To my knowledge, H.323 itself has no meachnism like SIPS, which would require the gatekeeper to use TLS for the next call signaling hop. =20 Regarding the lock item as such, from my current perception using a web browser, the lock icon indicates, that I have a secure connection from my browser to the server. As John wrote, I would expect the same semantic from my SIP client covering both, signaling and media connection. Regards Steffen >=20 > -d >=20 >=20 > > I think the distinction some of us are making is that while=20 > we agree=20 > > that some other hop by hop security mechanisms are appropriate, and=20 > > those mechanisms would use different mechanisms than all-TLS, sips=20 > > meaning all TLS is useful, and deployable, and we should=20 > clarify 3261=20 > > to achieve that. > >=20 > > I think all of us in that position also take the position=20 > that doing=20 > > something else, beyond clarifying sips, is useful, and=20 > should be done,=20 > > but should be called something other than sips. That is a lot more=20 > > work. I don't hear any voices saying just clarify sips as=20 > TLS end to=20 > > end with no further work. > >=20 > > I hear some people disagreeing that sips meaning TLS end to end is=20 > > useful. > > Some of those people want to simply deprecate sips and define=20 > > something else. Others want to redefine sips to be something else. > > The something > > else is the same something else I want. > >=20 > > I think we all tend to be agreeing on what that something=20 > else should=20 > > look > > like: it should describe desired security properties, it=20 > should allow=20 > > any suitable mechanism to achieve that goal, it should involve some=20 > > use of Require/Supported. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > > > Sent: Monday, October 30, 2006 1:46 PM > > > To: 'IETF SIP List' > > > Subject: RE: What controls the lock icon? (Was RE: [Sip] > > RE: TLS meaning) > > >=20 > > > I have removed most of the attribution below because the=20 > question of=20 > > > who said it, or what exactly he said, is not my point at=20 > the moment. > > >=20 > > > At 01:22 PM 10/30/2006, Someone wrote: > > > >Okay, let's tackle some of these issues. > > > > > > > >I think in order to be useful: > > > >sips: means .... > > > > > > > >Nothing else makes sense to me. > > >=20 > > > Having had several off line discussions with people who=20 > know their=20 > > > stuff very well about this SIPS issue, what has become=20 > very clear to=20 > > > me is that different participants have very different=20 > mental models=20 > > > of the relative roles and responsibilities of the proxies and the=20 > > > initiating / terminating UAs in the SIP exchanges. And different=20 > > > understandings of what the expressed user desire is when > > they say "sips:". > > >=20 > > > This then results in people saying "nothing else makes=20 > sense to me." > > > In fact, I still am having trouble understanding some of=20 > the points=20 > > > of view, because of this model conflict. (And I will=20 > readily admit=20 > > > that my mental model of what's going on may be wrong. =20 > But I can't=20 > > > seem to get to another one.) > > >=20 > > > We then end up talking past each other. > > >=20 > > > Yours, > > > Joel M. Halpern > > >=20 > > > PS: I am deliberately being a bit vague on the model=20 > mismatches for=20 > > > two reasons. Firstly, I think there are many more=20 > mismatches than=20 > > > just the ones between me and my correspondents. =20 > Secondly, I really=20 > > > don't want to mischaracterise other people's arguments. > > >=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 Tue Oct 31 02:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenaF-0008DU-Un; Tue, 31 Oct 2006 01:58:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenaD-0007zH-C1 for sip@ietf.org; Tue, 31 Oct 2006 01:58:49 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GenaB-0003HR-UE for sip@ietf.org; Tue, 31 Oct 2006 01:58:49 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9V62ICu008404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 00:02:19 -0600 In-Reply-To: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> References: <02f501c6fc50$621319c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 00:58:42 -0600 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'IETF SIP List' , "'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 On Oct 30, 2006, at 12:22 PM, Brian Rosen wrote: > Okay, let's tackle some of these issues. > > I think in order to be useful: > sips: means yes you must carry TLS through B2BUAs and anything else > that > could create an unsecure link > sips: means fail if you terminate on a gateway that interworks to a > non TLS > supported protocol, and the gateway must carry TLS through a > protocol that > supports TLS. With https:, the user agent can tell when the above doesn't happen. With sips:, it can't. Is circuit switched telephony a gateway that interworks to a "non TLS supported protocol"? -- 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 Oct 31 02:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenfE-00037v-Iq; Tue, 31 Oct 2006 02:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenfC-00037o-Gq for sip@ietf.org; Tue, 31 Oct 2006 02:03:58 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GenfB-0004Vc-6Q for sip@ietf.org; Tue, 31 Oct 2006 02:03:58 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9V67Utx008446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 00:07:30 -0600 In-Reply-To: <45464E61.6030305@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> <45464E61.6030305@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 01:03:53 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'IETF SIP List' , "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 On Oct 30, 2006, at 1:11 PM, Paul Kyzivat wrote: > So far I have heard that having a SIPS connection doesn't imply > that one can show this lock icon. What isn't yet clear to me is if > that means that SIPS is a necessary but insufficient condition, or > if SIPS is in fact not even helpful for providing it. I suspect it > isn't even helpful. If not, then what *is* driving the requirements > for SIPS? I think what is driving the requirement for sips: is the property I described in an earlier message -- the originator user is asking the proxies to only transmit this request over a secured link, and not to transmit it if they can't assure that level of security. This is kind of like the check-box "Fragile" on a UPS mailing request, where you're warning the handlers that the contents are fragile and asking them to treat it carefully. Of course, this sort of request sounds to me a lot more like a Requires/Proxy-Requires option tag, or a Caller Preferences tag, or some combination of those things, than it sounds like a URI scheme. But hey, we didn't know that yet when we were working on RFC 3261, and it seemed like we were talking about something that was kind of like https:, and thus sips: was born. -- 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 Oct 31 02:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenlQ-0006Ay-Tb; Tue, 31 Oct 2006 02:10:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GenlP-0006As-09 for sip@ietf.org; Tue, 31 Oct 2006 02:10:23 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GenlL-0005s4-LP for sip@ietf.org; Tue, 31 Oct 2006 02:10:22 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9V6DrNQ008498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 00:13:53 -0600 In-Reply-To: <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09C8234F-2946-4C48-854C-5CF5F4EEEF0E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 01:10:17 -0600 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.3) 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 On Oct 30, 2006, at 3:54 PM, Joel M. Halpern wrote: > Let me turn this around and ask the opposite stupid question. > What breaks if we say > 1) Every UAC and every proxy SHOULD utilize security on its > requests to the next hop for all requests. > 2) Every proxy must support TLS. Every UAC must be able to invoke > TLS. (Already required I believe.) > 3) Other mechanisms with equivalent security properties may be used > instead of TLS to meet (1). > > Then you don;t need SIPS. And there is no downgrade attack. I > will acknowledge that > a) this is not what 3261 says > b) that the equivalence in 3 is complex, and may open the door to > some folks making bad choices. But we already leave that door open > in other regards. The best solution is to be clear about what the > security properties are. > > Probably there is some obvious and simple reason the above is a bad > idea. > But this way it is no longer hammering at my skull for release. We lose the ability to demand security. That is, there'd be no way for a user to say "And if you can't send this securely, then don't send it!". Of course, we could combine what you have above with an option-tag providing the "demand" function I describe, and you;d have everything that sips: currently gives without having to use the sips: URI scheme. -- 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 Oct 31 02:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gennd-0007z3-Nq; Tue, 31 Oct 2006 02:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gennc-0007yv-1W for sip@ietf.org; Tue, 31 Oct 2006 02:12:40 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Genna-0006Ma-N2 for sip@ietf.org; Tue, 31 Oct 2006 02:12:40 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id D1CFBAC007; Tue, 31 Oct 2006 09:12:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17734.63332.804612.691080@harjus.tutpro.com> Date: Tue, 31 Oct 2006 09:12:36 +0200 To: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: References: <50B1CBA96870A34799A506B2313F26670A38D7FD@ntht201e.siemenscomms.co.uk> <45464E61.6030305@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'IETF SIP List' , Paul Kyzivat , "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 Dean Willis writes: > Of course, this sort of request sounds to me a lot more like a > Requires/Proxy-Requires option tag, or a Caller Preferences tag, or > some combination of those things, than it sounds like a URI scheme. > But hey, we didn't know that yet when we were working on RFC 3261, > and it seemed like we were talking about something that was kind of > like https:, and thus sips: was born. exactly, and now it is high time to correct the mistake and deprecate sips. -- 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 Tue Oct 31 02:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoKT-0003hT-3h; Tue, 31 Oct 2006 02:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoKQ-0003hL-Tn for sip@ietf.org; Tue, 31 Oct 2006 02:46:34 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeoKO-0005xS-KL for sip@ietf.org; Tue, 31 Oct 2006 02:46:34 -0500 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [70.79.3.186]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k9V7dlB25223; Tue, 31 Oct 2006 00:39:58 -0700 Message-ID: <4546FDB4.206@ntt-at.com> Date: Mon, 30 Oct 2006 23:39:32 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jeff Hodges , "Tschofenig, Hannes" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "sip@ietf.org List" Subject: [Sip] Concern with sending errors in SIP-SAML X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; SIP-Identity defines its own error response for when verification does not work(438) or when certificate that identity-info references is invalid(437). Now with certificate being embedded or be referenced in the SAML as SIP-SAML proposes, what happens when certificate embedded or referenced in the SAML assertion fails when verifying the signature attached by the authentication services? Should it return the error response defined in SIP-SAML or should it return the error response defined in SIP-Identity for when verification fails(438) or when certificate is invalid(437)? If it's the latter, proxy will need to be stateful to have the ability to recognize that it sent a reference to SAML assertion and not certificate alone, in order to handle the error properly. Whatever decision we come to, I believe we need to define this somewhere. Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 02:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoRw-0007b2-7r; Tue, 31 Oct 2006 02:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoRv-0007as-3U for sip@ietf.org; Tue, 31 Oct 2006 02:54:19 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GeoRr-0007az-JZ for sip@ietf.org; Tue, 31 Oct 2006 02:54:19 -0500 Received: (qmail invoked by alias); 31 Oct 2006 07:54:09 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 31 Oct 2006 08:54:09 +0100 X-Authenticated: #29516787 Message-ID: <4547011A.9080507@gmx.net> Date: Tue, 31 Oct 2006 08:54:02 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [Sip] Re: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications References: <453DD1C4.7080005@neustar.biz> <4546E074.6080203@ntt-at.com> In-Reply-To: <4546E074.6080203@ntt-at.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Jeff, Hi Shida, Shida Schubert wrote: > Hi Jeff; > > I saw the change in text below but the text following the > changed text concerns me a bit which may need to be changed > as well. > > ## Text from RFC4474 page 14 ########## > "HTTP and HTTPS URIs MUST follow the conventions of > RFC 2585 [10], and for > those URIs the indicated resource MUST be of the form > 'application/pkix-cert'" > > It reads like resource indicated by either HTTP or HTTPS has to be > a certificate, not something containing the certificate. Or I am reading > the text above incorrectly. That's also my reading of the text. To me this means that we have to define a new header as a consequence. Ciao Hannes > > Regards > Shida > > Jeff Hodges wrote: >> Tschofenig, Hannes wrote: >>>> * I'm not clear on how this mechanism works with older sip-identity >>>> implementations. The main issue is whether the URI in the >> identity-info >>>> header field will return just a certificate, as specified in >> sip-identity, >>>> or whether it returns a saml assertion. An older sip-identity verifier >>>> will expect a certificate but it will get an assertion if the AS >>>> implements sip-saml. Perhaps you are assuming that the Accept >> headers or >>>> something are used for this? Somehow this needs to be handled. >>> My understanding was that this got fixed with the SIP Identity draft. I >>> might, however, be worth to double-check it. >> I double-checked it, and I think we perhaps have an issue here. >> >> I see that the language of interest has now changed from (bottom of >> page 14 >> in -sip-identity-06).. >> >> The 'absoluteURI' portion of the Identity-Info header MUST contain >> either an HTTP or HTTPS URI which dereferences to a resource that >> contains a single MIME body containing the certificate of the >> authentication service. These URIs MUST follow the conventions of >> RFC2585 [10] and the indicated resource MUST be of the form >> 'application/pkix-cert' described in that specification. ... >> >> ..to this at the beginning of the second para of page 15 (in RFC4474).. >> >> The 'absoluteURI' portion of the Identity-Info header MUST contain a >> URI which dereferences to a resource containing the certificate of >> the authentication service. All implementations of this >> specification MUST support the use of HTTP and HTTPS URIs in the >> Identity-Info header. Such HTTP and HTTPS URIs MUST follow the >> conventions of RFC 2585 [10], and for those URIs the indicated >> resource MUST be of the form 'application/pkix-cert' described in >> that specification. ... >> >> >> Given the revised text above, I'm a tad concerned that implementors will >> interpret the 3d sentence to mean that their implementations need _only_ >> support HTTP/HTTPS URIs pointing to certificates as described in >> RFC2585, even >> though one _can_ interpret the above as also meaning that HTTP/HTTPS URIs >> pointing at resources other than certificates and/or CRL files are >> allowable, >> as long as the resource resolves one way or another into a >> "..certificate of >> the authentication service" (1st sentence above) -- as in a URI >> pointing to a >> SAML assertion containing such a cert. >> >> thoughts? >> >> thanks, >> >> =JeffH >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 Oct 31 04:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GepZr-0002rd-2l; Tue, 31 Oct 2006 04:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GepZp-0002mb-Dd for sip@ietf.org; Tue, 31 Oct 2006 04:06:33 -0500 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 1GepZo-0001Cn-3E for sip@ietf.org; Tue, 31 Oct 2006 04:06:33 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Z003BLTB6WK@siemenscomms.co.uk> for sip@ietf.org; Tue, 31 Oct 2006 09:06:42 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG5N7R>; Tue, 31 Oct 2006 09:06:31 +0000 Content-return: allowed Date: Tue, 31 Oct 2006 09:06:25 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: Hadriel Kaplan , 'Brian Rosen' , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F26670A3D793D@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: 25620135586de10c627e3628c432b04a 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 agree with Hadriel. There might be a need for some additional signalling element to indicate that we have reached PSTN, rather than a true endpoint, but as far as SIP is concerned if we have TLS all the way to the UAS, then that satisfies SIPS. John > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 31 October 2006 02:36 > To: 'Brian Rosen'; Elwell, John; 'IETF SIP List' > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > I'm not sure that's tenable. When the request reaches the > PSTN gateway, it > reached the UAS. It would be practically impossible to > define otherwise. > What would an IAD/MTA do, if it received a SIPS request but > would be ringing > a POTS/FXS interface in the house? What if that IAD were > physically in the > CO? What would a PBX do, key-system, etc. Or even if it > stayed IP - what > would a SIP-to-Skype inter-working gateway do, or an > enterprise system that > controlled phones with skinny/unistim/whatever. What would > it mean if the > UAS used H.248 or MGCP to control media gateways while sending the > "signaling" securely using sigtrans over TLS? > > SIPS asked for SIP over TLS. When it reached the SIPS UAS, it got it. > > -hadriel > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, October 30, 2006 1:23 PM > > > > I think in order to be useful: > > sips: means yes you must carry TLS through B2BUAs and > anything else that > > could create an unsecure link > > sips: means fail if you terminate on a gateway that > interworks to a non > > TLS > > supported protocol, and the gateway must carry TLS through > a protocol that > > supports TLS. > > > > Nothing else makes sense to me. > > > > For B2BUAs and SBCs and other things, I think there is a > simple test: if > > the > > ciphersuite included encryption, is the signaling encrypted > end to end? > > > > For gateways, I think talking about interworking to non TLS secured > > protocols is not what I want the sips success to mean. > It's not a secure > > TLS hop by hop end to end. This is especially true if the > gateway is to > > the > > PSTN. It does mean that a gateway that interworked to, say > H.323 could > > succeed with sips if it was possible to determine that the > H.323 signaling > > was TLS protected all the way. > > > > 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 Tue Oct 31 04:23:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gepny-0007jd-EI; Tue, 31 Oct 2006 04:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gepnv-0007jF-Ak for sip@ietf.org; Tue, 31 Oct 2006 04:21:08 -0500 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 1Gepns-0002MK-NW for sip@ietf.org; Tue, 31 Oct 2006 04:21:07 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Z00850TZETK@siemenscomms.co.uk> for sip@ietf.org; Tue, 31 Oct 2006 09:21:14 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG53FQ>; Tue, 31 Oct 2006 09:21:02 +0000 Content-return: allowed Date: Tue, 31 Oct 2006 09:21:01 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: "Joel M. Halpern" , 'IETF SIP List' Message-id: <50B1CBA96870A34799A506B2313F26670A3D7980@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: b5d20af10c334b36874c0264b10f59f1 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: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: 30 October 2006 21:55 > To: 'IETF SIP List' > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > The question is what "some other ... mechanisms are > appropriate" means. > Presumably, if SIPS means something useful (either TLS end to almost > end, or some other definition) our hope would be to teach users that > if they want security they should use SIPS. > If we are going to teach them that, and we are going to restrict SIPS > to TLS, then what does it mean to say that "some other hop by hop > security mechanisms are appropriate?" Does it mean that other > measures are appropriate if the user didn't ask for security? Does > it mean that we should make up another hop-wise secure URI > schema (I hope not.) > > The users don't care about what actual protocol is used to provide > the security. > And if they understand at all what a proxy is, and that there can be > intermediate proxies, then they presumably don't care which > intermediate proxies are in the path. > They presumably care that proxies do their job right, but that seems > to me to be a proxy issue, not an end user issue. > And proving that the "right" thing happened is clearly a very > different problem, with its own complications. [JRE] Apart from not understanding what a proxy is, users might not even understand what signalling is. They do understand the concept of eavesdropping on their speech or whatever. > > > Let me turn this around and ask the opposite stupid question. > What breaks if we say > 1) Every UAC and every proxy SHOULD utilize security on its requests > to the next hop for all requests. > 2) Every proxy must support TLS. Every UAC must be able to invoke > TLS. (Already required I believe.) > 3) Other mechanisms with equivalent security properties may be used > instead of TLS to meet (1). > > Then you don;t need SIPS. And there is no downgrade attack. I will > acknowledge that > a) this is not what 3261 says > b) that the equivalence in 3 is complex, and may open the door to > some folks making bad choices. But we already leave that door open > in other regards. The best solution is to be clear about what the > security properties are. [JRE] I guess this is at the back of my mind when I question the usefulness of SIPS. If a pair of proxies support TLS, why would they not always use TLS for exchanging requests? With connection re-use, proxies might set up a TLS connection and keep it. So any request, whether SIP or SIPS, will get routed over TLS. Routing a request over TCP or UDP in such cases would mean that TLS is not available. So a SIPS request would get rejected. Now this is fine if the caller is interested in making the call only if it can be a secure call (whatever that means), but in many cases the caller would want to accept an insecure call and the UAC would have to try again with SIP. So in this case, just doing best effort and notifying the UAC (and perhaps also the UAS) would be sufficient. The point is, how often does a UAC require TLS or nothing, as opposed to best effort TLS? And how often do proxies route SIP requests over TCP or UDP even though TLS would be available to SIPS requests? John > > Probably there is some obvious and simple reason the above is > a bad idea. > But this way it is no longer hammering at my skull for release. > > Yours, > Joel M. Halpern > > At 02:26 PM 10/30/2006, Brian Rosen wrote: > >I think the distinction some of us are making is that while > we agree that > >some other hop by hop security mechanisms are appropriate, and those > >mechanisms would use different mechanisms than all-TLS, sips > meaning all TLS > >is useful, and deployable, and we should clarify 3261 to > achieve that. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 Oct 31 04:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geq78-0000FC-2A; Tue, 31 Oct 2006 04:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geq6m-00089J-U9 for sip@ietf.org; Tue, 31 Oct 2006 04:40:37 -0500 Received: from harjus.tutpro.com ([192.98.100.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gepwk-0003H4-Au for sip@ietf.org; Tue, 31 Oct 2006 04:30:15 -0500 Received: by harjus.tutpro.com (Postfix, from userid 1000) id 3BE87AC007; Tue, 31 Oct 2006 11:30:13 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17735.6053.182282.83440@harjus.tutpro.com> Date: Tue, 31 Oct 2006 11:30:13 +0200 To: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Joel M. Halpern" , '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 Elwell, John writes: > TLS is not available. So a SIPS request would get rejected. Now this is fine > if the caller is interested in making the call only if it can be a secure > call (whatever that means), but in many cases the caller would want to > accept an insecure call and the UAC would have to try again with > SIP. i don't think that signaling security alone without media security means anything to common users. this is further justification of dropping sips. > So in > this case, just doing best effort and notifying the UAC (and perhaps also > the UAS) would be sufficient. The point is, how often does a UAC require TLS > or nothing, as opposed to best effort TLS? And how often do proxies route > SIP requests over TCP or UDP even though TLS would be available to SIPS > requests? it would make sense to always use tls out as long as the next hop supports it. there is no need for sips to tell that to the proxy. -- 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 Tue Oct 31 04:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geq9u-00036A-3B; Tue, 31 Oct 2006 04:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geq9s-00035w-9v for sip@ietf.org; Tue, 31 Oct 2006 04:43:48 -0500 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 1Geq9r-0004ws-0o for sip@ietf.org; Tue, 31 Oct 2006 04:43:48 -0500 Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0J7Z00E61V0ZLF@siemenscomms.co.uk> for sip@ietf.org; Tue, 31 Oct 2006 09:43:47 +0000 (GMT) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <49LG53YP>; Tue, 31 Oct 2006 09:43:36 +0000 Content-return: allowed Date: Tue, 31 Oct 2006 09:43:33 +0000 From: "Elwell, John" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) To: jh@tutpro.com Message-id: <50B1CBA96870A34799A506B2313F26670A3D79FD@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: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Joel M. Halpern" , '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: jh@tutpro.com [mailto:jh@tutpro.com] > Sent: 31 October 2006 09:30 > To: Elwell, John > Cc: Joel M. Halpern; 'IETF SIP List' > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: > TLS meaning) > > Elwell, John writes: > > > TLS is not available. So a SIPS request would get > rejected. Now this is fine > > if the caller is interested in making the call only if it > can be a secure > > call (whatever that means), but in many cases the caller > would want to > > accept an insecure call and the UAC would have to try again with > > SIP. > > i don't think that signaling security alone without media > security means > anything to common users. [JRE] Quite so. I was just making the (rather unsound) assumption that SIPS is a necessary aspect of achieving a secure call, including media security. As I said in other messages, I am far from convinced that SIPS is part of this story. > this is further justification of dropping > sips. > > > So in > > this case, just doing best effort and notifying the UAC > (and perhaps also > > the UAS) would be sufficient. The point is, how often does > a UAC require TLS > > or nothing, as opposed to best effort TLS? And how often > do proxies route > > SIP requests over TCP or UDP even though TLS would be > available to SIPS > > requests? > > it would make sense to always use tls out as long as the next hop > supports it. there is no need for sips to tell that to the proxy. [JRE] Thanks, that is what I suspected. > > -- 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 Tue Oct 31 07:25:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gescu-0002Ed-RR; Tue, 31 Oct 2006 07:21:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gesct-0002EX-5K for sip@ietf.org; Tue, 31 Oct 2006 07:21:55 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gescq-0001fP-So for sip@ietf.org; Tue, 31 Oct 2006 07:21:55 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GescZ-0001yL-2p; Tue, 31 Oct 2006 07:21:35 -0500 Message-Id: <7.0.1.0.0.20061031071800.034d6f50@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 31 Oct 2006 07:20:37 -0500 To: Dean Willis From: "Joel M. Halpern" Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <09C8234F-2946-4C48-854C-5CF5F4EEEF0E@softarmor.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> <09C8234F-2946-4C48-854C-5CF5F4EEEF0E@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b57112032ec25108862fb4a28a67d16714f49aa8a4b8a4ee4b2abb2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 While we currently have the ability to demand security, we actually have no way to reliably know whether we got it. If we can not tell if it is being delivered, why is being able to ask for it better than expecting the system to always deliver it? Yours, Joel PS: Just to be clear, the reason i say you can not tell if you got security is that even if we added extra recordings about what happens, I am pretty sure that two colluding proxies (such as a pair that have chosen to use IPSec instead of TLS, or have an old style telephony view and just trust their network and peering) will flat lie in order to deliver what they think is the service. At 02:10 AM 10/31/2006, Dean Willis wrote: >On Oct 30, 2006, at 3:54 PM, Joel M. Halpern wrote: > >>Let me turn this around and ask the opposite stupid question. >>What breaks if we say >>1) Every UAC and every proxy SHOULD utilize security on its >>requests to the next hop for all requests. >>2) Every proxy must support TLS. Every UAC must be able to invoke >>TLS. (Already required I believe.) >>3) Other mechanisms with equivalent security properties may be used >>instead of TLS to meet (1). >> >>Then you don;t need SIPS. And there is no downgrade attack. I >>will acknowledge that >>a) this is not what 3261 says >>b) that the equivalence in 3 is complex, and may open the door to >>some folks making bad choices. But we already leave that door open >>in other regards. The best solution is to be clear about what the >>security properties are. >> >>Probably there is some obvious and simple reason the above is a bad >>idea. >>But this way it is no longer hammering at my skull for release. > >We lose the ability to demand security. That is, there'd be no way >for a user to say "And if you can't send this securely, then don't >send it!". > >Of course, we could combine what you have above with an option-tag >providing the "demand" function I describe, and you;d have everything >that sips: currently gives without having to use the sips: URI scheme. > >-- >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 Oct 31 09:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeutQ-0007Ku-Mt; Tue, 31 Oct 2006 09:47:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeutK-0007Ko-AI for sip@ietf.org; Tue, 31 Oct 2006 09:47:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeutG-0000GB-UE for sip@ietf.org; Tue, 31 Oct 2006 09:47:02 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2006 06:46:58 -0800 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 k9VEkwKq013831; Tue, 31 Oct 2006 06:46:58 -0800 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 k9VEkwW4017142; Tue, 31 Oct 2006 06:46:58 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn7-379.cisco.com [10.21.145.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VEY9PN013615; Tue, 31 Oct 2006 06:34:09 -0800 Message-ID: <454761E4.8030207@cisco.com> Date: Tue, 31 Oct 2006 06:47:00 -0800 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: Juha Heinanen Subject: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) References: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> <17735.6053.182282.83440@harjus.tutpro.com> In-Reply-To: <17735.6053.182282.83440@harjus.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; 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=2752; t=1162306018; x=1163170018; 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:What=20consensus?=20(was=3A=20What=20controls=20the=20lock=20icon?=20(Wa s=20RE=3A=20[Sip]=0A=20RE=3A=20TLS=20meaning)); X=v=3Dcisco.com=3B=20h=3D1Ck+IMpUZSclPg4D5UnDImbZtOM=3D; b=wy/nRwDCJ57SMk/5s7aDpgn92TKrhzM9V+ZC3X5+suGp1pIY0/I2MUTz8otzgtdxk1VCuFMN 6nxCPxj43sY45qoarB+CHTvFM3svI/RLWSairci+qk80yqsSvw/HSE91; X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Joel M. Halpern" , 'IETF SIP List' , "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 So from where I'm sitting there seems to be a lot of people who are regular contributors to this list who either have doubts, or plain don't think SIPS is a good idea at all. In my experience, that is not rough consensus and usually means that the problem is not baked enough to get to rough consensus. That pretty much jibes with the current situation because there seems to be very little agreement as to what the problems that need to be solved are, let alone what the right solution is. Given how SIPS was rushed in at the last possible moment with a working group chomping at the bit to get a new RFC out, it's not clear to me that there was ever rough consensus on SIPS itself. The resulting years of disagreement pretty much bear out that lack of consensus. My advise to the working group is to just start over from first principles as if SIPS didn't even exist -- which in reality it doesn't. We need to be thinking about these things for the long term, and if it's not baked it's not baked. There have been many drafts that have lingered on and completely overhauled over the years. Why SIPS is treated so differently in that respect is somewhat mystifying because dealing with security for SIP is a genuinely hard problem. It shouldn't be rushed, and it deserves better than a kludgey security patina airbrushed in to get past the IESG. Mike Juha Heinanen wrote: >Elwell, John writes: > > > TLS is not available. So a SIPS request would get rejected. Now this is fine > > if the caller is interested in making the call only if it can be a secure > > call (whatever that means), but in many cases the caller would want to > > accept an insecure call and the UAC would have to try again with > > SIP. > >i don't think that signaling security alone without media security means >anything to common users. this is further justification of dropping >sips. > > > So in > > this case, just doing best effort and notifying the UAC (and perhaps also > > the UAS) would be sufficient. The point is, how often does a UAC require TLS > > or nothing, as opposed to best effort TLS? And how often do proxies route > > SIP requests over TCP or UDP even though TLS would be available to SIPS > > requests? > >it would make sense to always use tls out as long as the next hop >supports it. there is no need for sips to tell that to the proxy. > >-- 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 10:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gev8x-0006Sd-O8; Tue, 31 Oct 2006 10:03:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gev8v-0006SY-Oj for sip@ietf.org; Tue, 31 Oct 2006 10:03:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gev8q-0002uo-Jz for sip@ietf.org; Tue, 31 Oct 2006 10:03:09 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2006 07:03:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VF34fh015060; Tue, 31 Oct 2006 07:03:04 -0800 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 k9VF33Ao008050; Tue, 31 Oct 2006 07:03:03 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn7-379.cisco.com [10.21.145.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VEoFi6013975; Tue, 31 Oct 2006 06:50:15 -0800 Message-ID: <454765AB.2060509@cisco.com> Date: Tue, 31 Oct 2006 07:03:07 -0800 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: Brian Rosen Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> In-Reply-To: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=621; t=1162306984; x=1163170984; c=relaxed/simple; s=sjdkim1002; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning); X=v=3Dcisco.com=3B=20h=3DGRW9K/sCSuDWaouFDQAw+1n+V/c=3D; b=JfjPjQfoER93XJ03jHHjdYAelyW9307fy2hLJARLGKMyOJjq6XyM1X9xw+OqBRoeBplxsAo5 suYR7MR23lj8mbG2ij/WV3qRy+jHgmWPYNdA8H/u0Jx6qmhNdwdWBhNY; X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "'Joel M. Halpern'" , 'IETF SIP List' , '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 Brian Rosen wrote: >This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful. > > FSVO "useful". If this mechanism were actually "useful", would we be having this argument? Genuinely "useful" ideas have a tendency to route around the IETF if it is perceived as being old and in the way. Genuinely "useful" ideas also have a tendency to work out the initial ambiguities so that when it's time to rev the spec they emerged from it's a matter of documenting current practices. None of these things apply to SIPS. Indeed, the "useful" seems to be the enemy of the useful. 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 Tue Oct 31 10:11:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevEl-0000LA-K8; Tue, 31 Oct 2006 10:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevEg-0000IY-Ko for sip@ietf.org; Tue, 31 Oct 2006 10:09:07 -0500 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 1GevEc-00046X-9w for sip@ietf.org; Tue, 31 Oct 2006 10:09:06 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A703067C; Tue, 31 Oct 2006 10:08:51 -0500 From: "Hadriel Kaplan" To: "'Michael Thomas'" , "'IETF SIP List'" Subject: RE: [Sip] SIPS: why not S/MIME instead? Date: Tue, 31 Oct 2006 10:08:50 -0500 Message-ID: <008c01c6fcfe$7a10ec60$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb8RpCRPSj9EBaZQVib+3ITr7SRQwATwAQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45463250.7070103@cisco.com> X-Spam-Score: 0.1 (/) 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 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, October 30, 2006 12:12 PM > > As an alternative of my previous proposal, there seems to be quite a bit > of > unhappiness of the general bogosity of the last hop (UAS) exception of > SIPS. > If we remove that restriction, I guess I have to ask the question if you > want integrity/confidentiality along the path where you ultimately have no > real control over the transport chosen by middle proxies -- why don't > you just > get/learn the cert of the intended party and use S/MIME which actually > give > you the security properties that you're most likely hoping for with SIPS? Because UA's rarely have certificates, or ones worth trusting. And because to get that cert you would have had to have contacted the UAS using a signaling protocol (ie, SIP), so you've already done it. Even if you make it an options request or something benign, "they'll know". And then S/MIME is only a body and the message headers say a lot already - even if you have the sip headers copied+signed+encrypted in the s/mime body, they're in the clear in the message. So you'll want to encrypt+auth the whole sip message not just the body. And honestly there's probably a reason so many proxies are record-routing, or being b2bua's. Trying to bypass them is a Sysiphean task. > It seems to me that either S/MIME directly to the UAS or to some trusted > upstream agent for the UAS would be a *lot* better than hoping that you'll > get TLS the whole path, not least of which is that it eliminates the > lying > middle proxy problem. And if you're going to insist on TLS, you need > certs in all of those things anyway, so why not just ignore the TLS aspect > and use S/MIME? > > Which isn't to say that TLS is not useful, but SIPS is trying to > approximate > what S/MIME gets you, so it's not clear why you shouldn't we shouldn't > be promoting it instead of the obvious hack that SIPS is. Because S/MIME has been even less successful than SIPS (if that's possible). -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 Oct 31 10:22:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevPX-0006QY-IM; Tue, 31 Oct 2006 10:20:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevPT-0006Q3-5F for sip@ietf.org; Tue, 31 Oct 2006 10:20:17 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GevPP-0006Lv-Pi for sip@ietf.org; Tue, 31 Oct 2006 10:20:15 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 07:20:11 -0800 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 k9VFKBDL000339; Tue, 31 Oct 2006 07:20:11 -0800 Received: from dwingwxp ([10.32.240.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VFKAbF022974; Tue, 31 Oct 2006 07:20:10 -0800 (PST) From: "Dan Wing" To: "'Brian Rosen'" , "'Joel M. Halpern'" , "'IETF SIP List'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 07:20:10 -0800 Keywords: direct-to-dwing Message-ID: <012e01c6fd00$0e6c6550$c5f0200a@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: Acb8VDmSXYzxDt7AQk+GWI+9WZk5mwAAi3ygAAwk/lAAAiF1kAAb99lg In-Reply-To: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> DKIM-Signature: a=rsa-sha1; q=dns; l=2758; t=1162308011; x=1163172011; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning); X=v=3Dcisco.com=3B=20h=3D59UMOjsl4qSM1GeKz5v65xpvfWE=3D; b=PpSUwQtsV+vD9bG8xvnr1RCovIx5hxaDhp67RDdUoEamwRFffL0+SERo6tBSX1/jOlauqmyE tANBuYhIHUmP9aoU6qb2dk3zOUgMRDtHvtqsbTjnS/4BZS/X0o9eIA4n; 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: 244a2fd369eaf00ce6820a760a3de2e8 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 the correct interpretation. Similarly, if one end is on > > > the PSTN, then > > > you don't have TLS from end to end. > > > > According to RFC3261, I do -- the SIP endpoint is that PSTN > > gateway. > > > > With your argument, that PSTN gateway would have to reject > > the SIPS call setup attempt, the originator would have to > > send it via SIP, and possibly expose their signaling and > > media to IP-based eavesdroppers (RFC4568 requires using > > SIPS or S/MIME to protect the key in SDP), just because > > the last hop was the PSTN. > > Yes, I agree that's what you would have to do, which would be the > same circumstance if the first hop, which may very well be in a > domain that you can trust can't handle TLS. > > This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's > useful. I think we need to be fairly practical, and I also think we > need to think about what it means to the system as a whole, and not > JUST the UAC to UAS connection. If the signaling is not protected > end to end, then it's not "protected" and saying that a piece of it > is protected is not interesting to anyone. You might as well say > that there was at least one hop which was protected. I feel that > the PSTN is not protected signaling via TLS, and that's what sips > means to me. I think that is a useful mechanism, if it really means > TLS end to end. I don't think it's very useful if all it means is > one arc of UAC to UAS if the actual call has two or three such arcs > joined by B2BUAs, or one end is a PSTN connection. Ok. Makes sense. > There may be some yet to be defined security mechanism that allows a > more nuanced expression of what is acceptable, and what was > accomplished, but that's not sips, at least in my opinion. Right. What doesn't make sense, to me, is that we can only express a binary value. For example, when I'm at a coffeeshop using their WiFi, I don't want to have to downgrade my connection to my proxy to SIP (from SIPS) just because I'm calling the PSTN. > > We lack a mechanism for the PSTN gateway to say "it's > > secured up to me, and I'm the last hop and I can't > > make the PSTN do SIPS, sorry." We only have a > > mechanism for the PSTN gateway to say "I can't do SIPS". > > Yes, I agree, but that is just the same, to me, as a proxy > that can't do TLS > downstream, or a B2BUA that can't do TLS downstream. I don't > care WHY they > can't maintain secure signaling connections via TLS end to > end, I just know > they can't. That's what I want to know; my signaling is > protected end to > end via a hop by hop TLS mechanism. I am interested in working on a mechanism that allows signaling that condition. -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 Oct 31 10:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gevdb-0004vw-Hq; Tue, 31 Oct 2006 10:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevdX-0004tn-Bi for sip@ietf.org; Tue, 31 Oct 2006 10:34:47 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GevdU-0000Wm-04 for sip@ietf.org; Tue, 31 Oct 2006 10:34:47 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 07:34:43 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VFYhHA001006; Tue, 31 Oct 2006 07:34:43 -0800 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 k9VFYhW4004888; Tue, 31 Oct 2006 07:34:43 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn7-379.cisco.com [10.21.145.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VFLsZD014679; Tue, 31 Oct 2006 07:21:55 -0800 Message-ID: <45476D16.6020605@cisco.com> Date: Tue, 31 Oct 2006 07:34:46 -0800 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: Hadriel Kaplan Subject: Re: [Sip] SIPS: why not S/MIME instead? References: <008c01c6fcfe$7a10ec60$0500a8c0@acmepacket.com> In-Reply-To: <008c01c6fcfe$7a10ec60$0500a8c0@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2943; t=1162308883; x=1163172883; c=relaxed/simple; s=sjdkim1002; 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]=20SIPS=3A=20why=20not=20S/MIME=20instead?; X=v=3Dcisco.com=3B=20h=3DYqZNTs7XjPnD4yya7ij3kiCUKuU=3D; b=sLXVF/sQY4Mo8JVmxgextgzt1lG5feE/5UaACS7Dq3dpIvApYo+axv6YnsKiaS23DsRmeFUW foMjy/TNqF5W6kGyJ1mzZ8stoTmEZ3MEPxelfTnoT6c1ykYbl13mO/KK; X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Hadriel Kaplan wrote: > > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Monday, October 30, 2006 12:12 PM >> >>As an alternative of my previous proposal, there seems to be quite a bit >>of >>unhappiness of the general bogosity of the last hop (UAS) exception of >>SIPS. >>If we remove that restriction, I guess I have to ask the question if you >>want integrity/confidentiality along the path where you ultimately have no >>real control over the transport chosen by middle proxies -- why don't >>you just >>get/learn the cert of the intended party and use S/MIME which actually >>give >>you the security properties that you're most likely hoping for with SIPS? >> >> > >Because UA's rarely have certificates, or ones worth trusting. And because >to get that cert you would have had to have contacted the UAS using a >signaling protocol (ie, SIP), so you've already done it. Even if you make >it an options request or something benign, "they'll know". And then S/MIME >is only a body and the message headers say a lot already - even if you have >the sip headers copied+signed+encrypted in the s/mime body, they're in the >clear in the message. So you'll want to encrypt+auth the whole sip message >not just the body. >And honestly there's probably a reason so many proxies are record-routing, >or being b2bua's. Trying to bypass them is a Sysiphean task. > > Note first that I'm not trying to make light of the difficulties of S/MIME usage (which is largely the enrollment problem as you point out). But if SIPS is really supposed to be TLS to either to the UAS or a proxy one up from the UAS, aren't you left with the exact same enrollment problem regardless of whether it's TLS or S/MIME? Thus it seems to me that if all other things are equal, wouldn't you rather choose the one that at least eliminates the MITM attack inherent with hopwise TLS? Would it be a satisfactory state of affairs that S/MIME and/or e2e security was impossible because of these record-routing proxies and b2bua's? I sure hope not. >>Which isn't to say that TLS is not useful, but SIPS is trying to >>approximate >>what S/MIME gets you, so it's not clear why you shouldn't we shouldn't >>be promoting it instead of the obvious hack that SIPS is. >> >> > >Because S/MIME has been even less successful than SIPS (if that's possible). > > Beyond the enrollment problem, the same place you get TLS API's gets you S/MIME API's as well (openssl). So that's probably not the problem. Note that I'm not suggesting that S/MIME needs to necessarily be UAC to UAS. I've always thought that these things need to be though of in terms of "trust point" to "trust point", where "trust point" is whatever gives me comfort. A middle to middle that allows you to fly over dangerous territory may be exactly the right thing in many cases. 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 Tue Oct 31 10:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevqS-0003Vl-4Q; Tue, 31 Oct 2006 10:48:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GevqQ-0003Vb-So for sip@ietf.org; Tue, 31 Oct 2006 10:48:07 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GevqO-0002W4-AL for sip@ietf.org; Tue, 31 Oct 2006 10:48:06 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 Oct 2006 10:48:04 -0500 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 k9VFm4Hs015771; Tue, 31 Oct 2006 10:48:04 -0500 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 k9VFm3YJ028656; Tue, 31 Oct 2006 10:48:03 -0500 (EST) 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); Tue, 31 Oct 2006 10:48:03 -0500 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:48:01 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3021F282F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8V8eJg0q75zb6RA22y84zio7CLAAAhsOwACpThAA= From: "Michael Hammer \(mhammer\)" To: "Francois Audet" , "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-OriginalArrivalTime: 31 Oct 2006 15:48:03.0425 (UTC) FILETIME=[F33D5510:01C6FD03] DKIM-Signature: a=rsa-sha1; q=dns; l=12348; t=1162309684; x=1163173684; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning) |To:=22Francois=20Audet=22=20, =0A=20=20=20=20=20=20=20=20= 22Paul=20Kyzivat=20\(pkyzivat\)=22=20, =0A=20=20=20=20=2 0=20=20=20=22Elwell,=20John=22=20; X=v=3Dcisco.com=3B=20h=3DaFPK6TKLXx1aU0ofBm5AItr/iyM=3D; b=H2RNAwyMJC99L9k0hEXZS3t5dI5CJmnQYl/xP0nTcmKmyGMfN3pSOdna2vAnqoJLdO+LB73/ L41p7GwLaxltHxrKpeL/si7+U5eNZ1eAb0u3ao/3f2VU9HEzA2YpPfCp; 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: 142a000676f5977e1797396caab8b611 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 Francois, The problem is that the Web has set a precedent for what is expected of a "secure" Internet service. Using httpS means secure request; lock icon means it was accomplished. If user sees address sips, they will expect the same. =20 What will they think if no icon appears? What will they think if an icon appears? Both, cases indicate the inconsistency with https. Best to start over from square 1. Mike > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Monday, October 30, 2006 3:03 PM > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > I really don't understand why people keep on bringing the=20 > padlock thing again in the context of sips. >=20 > In a request-URI, sips is merely an indication that it is=20 > requested that all the hops (except possibly the last one)=20 > forward this request over TLS.=20 > RFC3261 uses a different URI scheme for that purpose as=20 > opposed to a Require header, but that's water under the=20 > bridge. That functionality is useful. >=20 > Many of us have explained over and over why being able to=20 > request that a request be sent securely over TLS is useful. >=20 > There is no implication of padlock icons here, neigher for=20 > the sender or >=20 > the receiver. >=20 > There are many aspects to security, and it's not clear to me=20 > that the role of IETF is to define the meaning of a padlock.=20 > Regardles, I can think of the following attribute:=20 >=20 > - Are MIME bodies (including SDP) encrypted end-to-end using S/MIME? >=20 > - Are selected parts of the SIP message itself and MIME=20 > bodies (including SDP) > integrity protected end-to-end using SIP Identity (as per RFC 4474)? >=20 > - Are the whole SIP message itself and MIME bodies=20 > (including SDP) integrity > protected end-to-end using S/MIME (as per RFC 3993)? >=20 > - Is media encrypted end-to-end using SRTP? >=20 > - Is the key negotiation used for that secured end-to-end=20 > using encryption (e.g., > MIKEY, SDESC with S/MIME). >=20 > - Is the identity of the user sending the request secured=20 > with sip-identity (RFC 4474)? >=20 > - Are request mapped to a non-SIP network considered "secure"=20 > (e.g., PSTN, H.323, etc.)? >=20 > - Can we protect against B2BUA and the likes?=20 > - etc. >=20 > In short, there are many aspects to this, including (but not limited > to): >=20 > - Authentication of users >=20 > - Integrity protection >=20 > - Encryption of signalling >=20 > - Encryption of media >=20 > - End-to-end versus hop-by-hop >=20 > - Hop-of to another network (e.g., PSTN, H.323, etc.)=20 >=20 > - What cyphersuites are used >=20 > - etc. >=20 > It is not clear to me at all that we (SIP WG) can specify=20 > what the padlock icon should be.=20 > Different network deployment may wish to convey different=20 > information to end-users. >=20 > In some deployment, you may want an indication that=20 > everything is encrypted/authenticated end-to-end (security,=20 > media, identity, etc.) using a consolidated icon. > In other deployment, > maybe hop-by-hop is the desired behavior (e.g., inside an=20 > enterprise where lawful intercept may be view as secure). >=20 > In some other deployment, you amy want different padlock=20 > icons for different security properties. Or different levels=20 > of security. >=20 > The point is, this is NOT SIPS. It's something else. If we=20 > decide to tackle it or not is another issue. I personally=20 > think it is a pretty tall order, and I'm not sure it's the=20 > mandate of IETF. For now, I just want to ensure that we=20 > don't confuse padlock with SIPS. >=20 >=20 > Cheers. >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Monday, October 30, 2006 11:11 AM > > To: Elwell, John > > Cc: 'IETF SIP List' > > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE:=20 > > TLS meaning) > >=20 > > I support John here. As stupid as it might seem, I think=20 > this little=20 > > thing is likely to be very important. And figuring out what=20 > it takes=20 > > to have it is a way at getting to underlying requirements=20 > for security=20 > > in the protocol. Perhaps there are also other requirements for=20 > > security, but at least this would provide one source. > >=20 > > So far I have heard that having a SIPS connection doesn't=20 > imply that=20 > > one can show this lock icon. What isn't yet clear to me is if that=20 > > means that SIPS is a necessary but insufficient condition,=20 > or if SIPS=20 > > is in fact not even helpful for providing it. I suspect it=20 > isn't even=20 > > helpful. > > If not, then what *is* driving the requirements for SIPS? > >=20 > > I think I would also extend John's proposal a bit. I think=20 > there *may*=20 > > need to be different levels of security, where the lock icon=20 > > corresponds to one of them. But this is a slippery slope,=20 > because if=20 > > there are too many they become confusing to users. But too=20 > few of the=20 > > wrong ones may not be useful in practice. > >=20 > > For instance, it may be that there is a need for "PSTN quality"=20 > > security. (I imagine that *ought* to be the same as "none", but in=20 > > practice I think the PSTN level security is better than basic=20 > > unsecured-sip-over-internet security, so knowing you had this when=20 > > connected to the PSTN could be helpful.) But a "really=20 > secure" (better=20 > > than PSTN) would be a great way of motivating deployment of=20 > IP-based=20 > > e2e telephony services. > >=20 > > Paul > >=20 > > Elwell, John wrote: > > > Some of the discussion on the long thread on "TLS meaning"=20 > > has led me > > > to seek opinions on what does indeed control the lock icon, > > since we > > > seem to have consensus that a successful SIPS request is > > not grounds > > > for showing the lock icon. > > >=20 > > > The user surely will expect media to be secured end-to-end. By=20 > > > end-to-end, I mean at least as far as the domain the user=20 > believes=20 > > > he/she is in communication with. So there has to be some > > cryptographic > > > assurance that the entity with which the UA agrees keys for media=20 > > > security has the credentials of the entity indicated by caller or=20 > > > connected party identity (From+Identity or possibly PAI). This is=20 > > > probably a sufficient condition if key agreement is carried > > out using > > > D-H. If the key is transported, then an additional > > condition is that > > > the key is end-to-end encrypted, which for SDescriptions > > means encrypted using S/MIME. > > >=20 > > > But what about the presence of B2BUAs, SBCs, etc. that do > > not have the > > > credentials of the end user but nevertheless terminate > > media security?=20 > > > Here the UA could find that it does media negotiation with=20 > > > service-provider.net rather than with the end user > > (user@example.com).=20 > > > It seems the lock item should not be displayed in this > > situation. Or > > > maybe the user could be consulted whether he/she accepts the=20 > > > certificate of the intermediary even though it fails to > > identify the remote user. > > >=20 > > > Another situation is where a user is trying to contact > > > +123456789@example.com but gets back a From/Identity indicating=20 > > > +123456789@service-provider.net and media is secured as far as > > > service-provider.net. Does this constitute grounds for > > displaying the icon? > > >=20 > > > John > > >=20 > > >> -----Original Message----- > > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > >> Sent: 29 October 2006 21:26 > > >> To: 'EKR'; 'David R Oran' > > >> Cc: 'Joel M. Halpern'; 'IETF SIP List'; 'Paul Kyzivat';=20 > 'Francois=20 > > >> Audet'; 'Dean Willis' > > >> Subject: RE: [Sip] RE: TLS meaning > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Eric Rescorla [mailto:ekr@networkresonance.com] > > >>> Sent: Saturday, October 28, 2006 9:34 AM > > >>> >From a security perspective, SIPS has two important properties: > > >>> > > >>> 1. It says to the client "you MUST talk to me over SSL". > > >> I hope it doesn't say that. I thought we had to use TLS. ;) > > >> > > >> > > >>> 2. It says to the proxies "I expect you to make the outgoing > > >>> connection with TLS". > > >>> > > >>> As Samir has observed, the second property can be > > provided with some > > >>> indicator in the SIP header. However, the first can only > > be provided > > >>> by putting the indicator in the reference which you hand > > >> around (i.e., > > >>> the SIP URI). This isn't to say it necessarily has to be > > a new URI > > >>> scheme--though it did in HTTP because HTTP doesn't have=20 > > >>> parameters--but it's not clear to me that moving it to=20 > parameters=20 > > >>> would really help. > > >> I think the part some of us are worried about is it will > > inherit the > > >> perception of https: namely that the entire path from the > > caller to > > >> the answerer is secure. Just because an IETF doc says > > it's not the > > >> same, and says it's not a lock icon, will not overcome the=20 > > >> perception. > > >> Even though an > > >> https connection is only secure to the TLS terminator (the > > server or > > >> an offloader), and the back-end from there is not, the > > assumption is > > >> the owner of the terminator takes on the responsibility=20 > from there=20 > > >> (if there is any responsibility). And the terminator > > owner wanted to > > >> secure it between the browser and the terminator, and they > > got that. > > >> > > >> But SIP is neither HTTP nor SMTP. The sips uri may end=20 > at a pstn=20 > > >> gateway, or an h323 IWF, or whatever. It may become sip=20 > later, as=20 > > >> well. The owner of the TLS terminator does not > > necessarily equal the > > >> owner of the final UAS, nor the owner of the answerer. =20 > > How can the > > >> owner of the terminator have any responsibility for=20 > something that=20 > > >> may happen somewhere else, unbeknownst to him? How/why > > would someone > > >> who types in a sips uri for their request not think it's > > like https? > > >> > > >> In some ways the perception problem is exacerbated by the > > uri being > > >> the sips scheme. If it were a require/proxy-require instead, it=20 > > >> would help alleviate that perception problem, IMO. But > > then you're > > >> left with trying such a request without the foreknowledge > > of success > > >> probability that a business-card sips address would give you. > > >> > > >> -hadriel > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > _______________________________________________ > > > 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 Tue Oct 31 11:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewAl-0006IG-RH; Tue, 31 Oct 2006 11:09:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewAj-0006Ea-PJ; Tue, 31 Oct 2006 11:09:05 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gew71-00050R-9N; Tue, 31 Oct 2006 11:05:25 -0500 Received: from [172.17.1.79] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id k9VG57tx011888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Oct 2006 10:05:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45477421.2080305@nostrum.com> Date: Tue, 31 Oct 2006 10:04:49 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Cc: SIP WG , "'rohc@ietf.org'" , Keith Drage , Dean Willis Subject: [Sip] Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "'rohc@ietf.org'" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have been asked to perform a dedicated review on the document draft-ietf-rohc-sigcomp-sip-03. My comments follow. Note that I have implemented this specification, any many of my comments arise from issues I identified during such implementation. ------------------------------------------------------------------------ Remote identifiers in outgoing requests: The current document uses the "+sip.instance" Contact header-field parameter (if present) to identify compartments, and the sigcomp-id parameter otherwise. Page 9 contains specific text that specifies that senders SHOULD NOT include a sigcomp-id parameter if the URI is being conveyed in a SIP contact header field which includes a "+sip.instance" parameter. Unfortunately, this doesn't work very well in practice; the root cause of the problems that arise is that the ability to receive compressed messages is fundamentally tied to the URI. Semantically separating the compartment identifier from the URI breaks this a bit. So, for example, if I were to fit this into the resiprocate code base, I would need to perform all manner of cross-layer plumbing and make some really ugly SigComp-related hacks all the way up in the registry code. The problems that arise, however, are probably best demonstrated using a network in which the proxy that performs SigComp compression and decompression is not the same network element as the registrar. User Agent Edge Proxy Proxy Registrar | | | | | | | | | |REGISTER | | |------------------>| | |Contact: ;+sip.instance= | | | | |REGISTER | | |------------------>| | |Contact: ; | | +sip.instance= | |Path: | | | | |200 | | |<------------------| | |Path: | | | |200 | | |<------------------| | |Path: | | | | Time Passes User Agent Edge Proxy Proxy Registrar | | | | | |<-- INVITE -- | | | | |INVITE sip:user@ua;comp=sigcomp | |<------------------| | |Route: | | | | | | |INVITE sip:user@ua;comp=sigcomp | |<------------------| | |How does the EP know which compartment to use? | | | | | | | | | Here, the problem arises because the Contact header field parameter isn't visible to the edge proxy on subsequent messages. Once again, the fundamental issue here is that the compartment identifier really needs to be an integral part of the URI, as opposed to a header field parameter. I would propose removing the use of +sip.instance for compartment identification at all. That said, the draft should point out the value of using the same identifier for the +sip.instance parameter on the Contact header field and the sigcomp-id on the URI in the contact header: by using the same identifier in both places, you'll get *really* good compression of the second one in almost all compression schemes. (In other words: 'Contact: ;+sip.instance=""' will compress pretty well because of the high degree of redundancy). ------------------------------------------------------------------------ Identification of messages in incoming requests without a "sigcomp-id" parameter: the draft currently says that these should be identified by the "sent-by" parameter of the top most Via header field, for legacy compatibility. This raises a few issues. First: this should almost certainly be "the received parameter, if present; and the sent-by field otherwise." In particular, an edge proxy is likely to see a *TON* of devices that have placed, e.g., "192.168.0.100" (or choose any other NAT default DHCP address) in the sent-by field. They will not all correlate to the same user agent. Second: the draft doesn't indicate whether the port number should be taken into account. Finally, in legacy applications, my experience (from SIPits) is that the predominant legacy means of compartment identification is to use the IP Address/Port for datagram messages, and the actual TCP connection itself for stream messages. I would propose that we will achieve the greatest compatibility with legacy applications if we use the same scheme. ------------------------------------------------------------------------ Outgoing responses: Because of the way SIP handles Via header fields, any compartment identifier present in the Via header field for an inbound request will be copied into the outgoing response. This might not be immediately obvious to implementors, so it probably bears mentioning. e.g: Outgoing responses: the remote application identifier is the same as the previously-received request that initiated the transaction the response belongs to. Note that, due to standard SIP Via header field processing, this identifier will be present in the top-most Via header field in such responses. ------------------------------------------------------------------------ Although not a bug in the draft per se, in implementing this specification, I encountered an interesting situation: the use of the "comp=sigcomp" parameter on URIs used in Record-Route requires considerable thought, and should probably be discussed in the draft. In particular, a proxy wants to advertise the route towards the client as supporting SigComp; however, advertising the route towards the core of the network might lead to the unfortunate case in which proxies in the core of the network are using SigComp to talk to each other. Consequently, proxies that implement this mechanism will want to insert two route headers in dialog-establishing requests: the one towards the client will indicate "comp=sigcomp" on its URI; while the other one will not. ------------------------------------------------------------------------ I'm having a lot of difficulty parsing the final paragraph in section 3.2: Compressors that make use of initial state memory MUST implement the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077]. (Note that there is no such requirement on decompressors, but see also Section 6.) For this requirement, initial state memory is defined as the assumption of a non-zero SMS value before having received an advertisement of non-zero SMS (e.g., via returned parameters as specified in section 9.4.9 of [RFC3320]); ANY/SigComp as defined in [RFC3320] does not have initial state memory. There are two separate points of confusion for me: 1. I don't understand the assertion that decompressors don't need to implement RFC 4077. Decompressors serve the critical role of generating NACK messages when decompression fails. (And, in fact, text at the end of section 6.3 implies that NACK implementation is required in decompressors as well). 2. The document has already established that stateless compression (i.e., compression that doesn't take advantage of initial state memory) is pointless for SIP endpoints -- so the clause "Compressors that make use of initial state memory" pretty much collapses to just "Compressors." So, unless I've missed something, this paragraph should be rewritten as: SIP/SigComp endpoints MUST implement the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077]. It's not clear that it belongs in section 3.2 after being simplified; in fact, it seems to be redundant with the entire contents of section 3.4. ------------------------------------------------------------------------ Section 6.1: This section asserts that the URN used to identify compartments MUST be persistent across reboots. While this isn't necessarily a *harmful* property, I don't understand its utility. In particular, this requirement adds additional implementation complexity to edge proxies that wouldn't otherwise have to persist this information. Thinking about this from another angle: if an implementation isn't persisting compartment *STATES* across reboots, what value is there in persisting compartment *IDENTIFIERS* across reboots? ------------------------------------------------------------------------ Nit: for clarity, the ANBF describing the SIP URI sigcomp-id parameter should probably call it something like "uri-sip-sigcomp-id" instead of just "sip-sigcomp-id" (to better distinguish it from "via-sip-sigcomp-id"). ------------------------------------------------------------------------ Nit: The angle brackets for the via header field parameter sigcomp-id seem superfluous -- or, at the very least, redundant with the quotation marks. I suspect this syntax was "borrowed" from the draft-ietf-sip-outbound syntax for "+sip.instance", which, in turn, is dictated by RFC 3840. RFC 3840 includes this notation because the "+sip.instance" string, when used with callee caps, is used for equality comparison as a quoted string: If the filter is an equality over a quoted string, the output is a less than (<), followed by the quoted string, followed by a greater than (>). This doesn't apply to what we're doing here, so the angle brackets don't seem necessary. ------------------------------------------------------------------------ Nit: The example of a sigcomp-id parameter on page 8 uses a colon instead of an equals sign after "sigcomp-id". ------------------------------------------------------------------------ There is text on page 11 (starting "As there is no way to signal...", and continuing to the end of the paragraph) which appears to be obsoleted by section 3.4. ------------------------------------------------------------------------ The first two paragraphs of section 6.5 talk about the mechanisms by which registrars can be non-adjacent to the registering user agent in a network. The third paragraph then seems to make an assumption that registrars must always be adjacent to the registering user agent -- it assumes that the "SIP application generating a 200 response for a REGISTER" is also the node performing compression. Beyond this point, I think I simply don't understand what the third paragraph is trying to say. I think the text needs to be cleaned up significantly. Finally, in the case of non-adjacent registrars, section 6.5 appears to require the edge proxy (that is, the proxy implementing SigComp) to track registration state. If this is the intention, it should be explicitly called out. ------------------------------------------------------------------------ Similar to section 6.5: section 6.6 requires proxies that perform SigComp compression to become both dialog stateful, including tracking of multiple usages within a dialog. This verges on terrifying, from an implementation perspective. ------------------------------------------------------------------------ Section 6.3 through 6.6 in general: I think we're making this much more complicated than it needs to be. Compression for a single transaction will never be a win. Bytecode overhead will eat any savings on the request; then, bytecode overhead will eat any savings on the response. Then, the transaction will be over. In practice, I've never seen a case in which these first messages don't expand. So, overall, opening a compartment for a single transaction will be a net loss. You're better off not compressing. Compression for a dialog, for similar reasons, is likely to be a wash in most cases. In particular, one of the strongest motivators for SigComp in current applications is reduction of call setup times. If you're expanding the first message sent in either direction, you lose this advantage altogether. So, in practice, the only construct that really seems to make much sense for compartment lifetime is registration. I would argue that we should describe the compartment lifetime as being bound to a registration (with the option to keep them open longer), and leave it at that. ------------------------------------------------------------------------ The description of service route and path handling in the example is confusing at best; I think it's probably outright inaccurate: When the outbound proxy receives a 200 (OK) response (3) for the REGISTER request, it constructs the route future incoming requests will follow (using the Contact and the Path header fields) and the route future outgoing requests will follow (using the Contact and the Service-Route header fields). Both the Path and the Service-Route header fields contain the outbound proxy's URI. The Contact header field contains the user agent's URI, which carries the user agent's SIP/SigComp identifier 'UA-id'. The problem that I see with this text is that it implies that the outbound proxy is somehow in charge of storing the Path and the Service-Route for the duration of the registration. In practice, the User Agent stores the Service-Route, and the registrar (or some adjunct proxy to the registrar) stores the Path. The only role the outbound proxy can play in this is by inserting itself into the Service-Route and Path at registration time. For the Path, this is done when the REGISTER message passes through it, not when the 200 response to the REGISTER passes through it. For Service-Route, RFC 3608 is very clear that the outbound proxy can't play a role in the construction of the service route (see section 6.2 of RFC 3608). Continuing: On receiving the 200 (OK) response (4), the user agent constructs the route future incoming requests will follow (using the Path header field) and the route future outgoing requests will follow (using the Service-Route header field). The user agent is supposed to open a new compartment for 'Outbound-id' for the duration of the registration, as discussed in Section 6.4. However, since the user agent has already a compartment for 'Outbound-id', it reuses that comparment, as discussed in Section 6.3. The user agent doesn't use the Path header field for anything (RFC 3327, section 5.1: "The general operation of the UA is to ignore the Path header field in the response.") ------------------------------------------------------------------------ Nit: The example section really should include at least one representative SIP message demonstrating the syntax of the new parameters. Here's one you can use (making some assumptions about the resolution of points I raised above): REGISTER sip:estacado.net SIP/2.0 Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav; rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473" From: "Joe User" ;tag=6to4gh7t5j To: "Bob User" Call-ID: 3c26700c1adb-lu1lz5ri5orr CSeq: 215196 REGISTER Max-Forwards: 70 Contact: ; q=1.0; +sip.instance="" Expires: 60 Content-Length: 0 ------------------------------------------------------------------------ Appendix A is a cut-and-paste from draft-ietf-rohc-sigcomp-impl-guide, which will almost certainly beat draft-ietf-rohc-sigcomp-sip to RFC. I think you really just want a normative reference to draft-ietf-rohc-sigcomp-impl-guide to refer to the well-known shim. (This also impacts the final paragraph of section 4). ------------------------------------------------------------------------ Please discuss on the ROHC mailing list, as this is a ROHC working group item. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 11:19:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewIE-0008S9-MM; Tue, 31 Oct 2006 11:16:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewB3-0006EZ-VJ for sip@ietf.org; Tue, 31 Oct 2006 11:09:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gevwu-0003bf-UU for sip@ietf.org; Tue, 31 Oct 2006 10:55:15 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 07:54:48 -0800 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 k9VFsmDW026176; Tue, 31 Oct 2006 07:54:48 -0800 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 k9VFseOn013219; Tue, 31 Oct 2006 07:54:48 -0800 (PST) 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); Tue, 31 Oct 2006 10:54:44 -0500 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:54:43 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3021F283F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8V8eJg0q75zb6RA22y84zio7CLAAAhsOwACqfwTA= From: "Michael Hammer \(mhammer\)" To: "Francois Audet" , "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-OriginalArrivalTime: 31 Oct 2006 15:54:44.0711 (UTC) FILETIME=[E26CB770:01C6FD04] DKIM-Signature: a=rsa-sha1; q=dns; l=783; t=1162310088; x=1163174088; c=relaxed/simple; s=sjdkim6002; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3DaFPK6TKLXx1aU0ofBm5AItr/iyM=3D; b=HNCGHpNeNB+O/jv8WNJBd1g83n+6rjrS4zMbKmM9uYkY7MXFM+W4bpi/amD3RJGCUZB32UWU PTFSEmEWFl7TupNpghCJHXMCJhjywjHlnT4sfi5DAz3+RgIdQtOf7h/D; Authentication-Results: sj-dkim-6.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 BTW, I don't have a problem with some of the behaviors described, just stop the false advertizing aspect. Also, it would be clearer if there is a distinction between using a sips address and having "sips-like" signaling behavior. I don't always know when someone says "SIPS" if it is mean euphemistically. You could have sips-like behavior, but not use sips:URI. Mike > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Monday, October 30, 2006 3:03 PM > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > I really don't understand why people keep on bringing the=20 > padlock thing again in the context of 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 Tue Oct 31 11:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewPs-00004x-B3; Tue, 31 Oct 2006 11:24:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewPm-0008VP-DL for sip@ietf.org; Tue, 31 Oct 2006 11:24:38 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewPb-0000Ln-1v for sip@ietf.org; Tue, 31 Oct 2006 11:24:38 -0500 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 k9VGOOX21776; Tue, 31 Oct 2006 11:24:24 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:24:20 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC99488@zrc2hxm0.corp.nortel.com> In-Reply-To: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8zih6W2L2yt9MRRiCpRct2sHwugAOUSzA From: "Francois Audet" To: "Elwell, John" , "Joel M. Halpern" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 > [JRE] Apart from not understanding what a proxy is, users=20 > might not even understand what signalling is. They do=20 > understand the concept of eavesdropping on their speech or whatever. If we had a way to do media security in the media channel, as we are investigating in RTPSEC, then that issue would be solve. To me, that would be a good "padlock icon". In conjunction with sip-identity, we'd have a pretty good solution.=20 To me, that "verified User" padlock would also be useful. > [JRE] I guess this is at the back of my mind when I question=20 > the usefulness of SIPS. If a pair of proxies support TLS, why=20 > would they not always use TLS for exchanging requests? With=20 > connection re-use, proxies might set up a TLS connection and=20 > keep it. So any request, whether SIP or SIPS, will get routed=20 > over TLS. Routing a request over TCP or UDP in such cases=20 > would mean that TLS is not available. So a SIPS request would=20 > get rejected. Now this is fine if the caller is interested in=20 > making the call only if it can be a secure call (whatever=20 > that means), but in many cases the caller would want to=20 > accept an insecure call and the UAC would have to try again=20 > with SIP. So in this case, just doing best effort and=20 > notifying the UAC (and perhaps also the UAS) would be=20 > sufficient. The point is, how often does a UAC require TLS or=20 > nothing, as opposed to best effort TLS? And how often do=20 > proxies route SIP requests over TCP or UDP even though TLS=20 > would be available to SIPS requests? SIPS is useful when you are prepared to have a session fail if it is not made securily. It's as simple as that. So yes, it is useful. Is it a panacea? Absolutely not. Is TLS without SIPS useful (i.e., for a best-effort like service)? Absolutely. Is it more useful than SIPS? Probably (at least, I think so). I would certainly implement SIP over TLS (with SIP scheme) before implementing sips if I couldn't do both. That does not mean that sips is NOT useful. >From the REAL requirements that I have seen, there is definitively a need for the following: 1) No TLS 2) Best-effort TLS (do it if you can) 3) Always TLS (i.e., fail the request if it cannot be on all hops). 3a) This can be on a per-request session basis. 3b) This can be for a specific address (e.g., sips:hotline@example.com) Could we have implemented the functionality of sips without a new URI scheme? Yes, we could have used a Proxy-Require for example. Would it have been better? Probably. But, it's too late for that. There are many other examples of=20 sub-optional design in RFC 3261... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 11:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewZ5-0004sG-AS; Tue, 31 Oct 2006 11:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewZ2-0004rL-P6 for sip@ietf.org; Tue, 31 Oct 2006 11:34:12 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewYj-0001nM-Lf for sip@ietf.org; Tue, 31 Oct 2006 11:34:12 -0500 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 k9VGXn729102; Tue, 31 Oct 2006 11:33:49 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:33:42 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC994D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3021F282F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8V8eJg0q75zb6RA22y84zio7CLAAAhsOwACpThAAAAZT94A== From: "Francois Audet" To: "Michael Hammer \(mhammer\)" , "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Tuesday, October 31, 2006 7:48 AM > To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat);=20 > Elwell, John > Cc: IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > Francois, >=20 > The problem is that the Web has set a precedent for what is=20 > expected of a "secure" Internet service. >=20 > Using httpS means secure request; lock icon means it was accomplished. >=20 > If user sees address sips, they will expect the same. =20 >=20 > What will they think if no icon appears? > What will they think if an icon appears? >=20 > Both, cases indicate the inconsistency with https. Best to=20 > start over from square 1. Euh, no it ain't. We can't deprecate RFC 3261.=20 There are many things that aren't that great in RFC 3261, and we are not deprecating it. Like it or not RFC 3261 is now commercial. It doens't matter what a bunch of technies like us think, we can't just pull the carpet from under it for architecture purity's sake. SIPS is just one of them. Like UDP transport, forking proxies, early media, ambiguity of offer/answer, pre-conditions, SDP in itself, PRACK, UPDATE, Contacts, the RTCP=3DRTP+1 rule, bizarre case-sensitivity rules, strict routing, etc. etc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 11:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewYn-0004p7-IX; Tue, 31 Oct 2006 11:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewYl-0004oY-Az for sip@ietf.org; Tue, 31 Oct 2006 11:33:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewYb-0001m3-04 for sip@ietf.org; Tue, 31 Oct 2006 11:33:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 08:33:45 -0800 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 k9VGXiiB005709; Tue, 31 Oct 2006 11:33:44 -0500 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 k9VGXiDM028600; Tue, 31 Oct 2006 11:33:44 -0500 (EST) 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, 31 Oct 2006 11:33:44 -0500 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:33:44 -0500 Message-ID: <45477AE6.8000109@cisco.com> Date: Tue, 31 Oct 2006 11:33:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> In-Reply-To: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 16:33:44.0322 (UTC) FILETIME=[54F10620:01C6FD0A] DKIM-Signature: a=rsa-sha1; q=dns; l=2603; t=1162312424; x=1163176424; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning) |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3Dr0kv6ZvsYOsda2FiXktGBPaN+fc=3D; b=ID5Xib1g92xW641GqDktEOgkg07/4rnGhcZoSb+CqVn7TQSmfWZOZTdbkblkeLOwmZcIsOzu hZeyaXTh8QRagtx3mnzq+u4Hb3e28y7LwXZOpSB6jo/dsproj2UbnywJ; 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: "'Joel M. Halpern'" , 'IETF SIP List' , '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 Brian, With your expectation about the meaning of SIPS, what is your attitude about TLS offloaders? The link from the offloader to the server isn't TLS. Does that mean a server using an offloader can't support SIPS? Paul Brian Rosen wrote: >>> is the correct interpretation. Similarly, if one end is on >>> the PSTN, then >>> you don't have TLS from end to end. >> According to RFC3261, I do -- the SIP endpoint is that PSTN >> gateway. >> >> With your argument, that PSTN gateway would have to reject >> the SIPS call setup attempt, the originator would have to >> send it via SIP, and possibly expose their signaling and >> media to IP-based eavesdroppers (RFC4568 requires using >> SIPS or S/MIME to protect the key in SDP), just because >> the last hop was the PSTN. > Yes, I agree that's what you would have to do, which would be the same > circumstance if the first hop, which may very well be in a domain that you > can trust can't handle TLS. > > This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful. > I think we need to be fairly practical, and I also think we need to think > about what it means to the system as a whole, and not JUST the UAC to UAS > connection. If the signaling is not protected end to end, then it's not > "protected" and saying that a piece of it is protected is not interesting to > anyone. You might as well say that there was at least one hop which was > protected. I feel that the PSTN is not protected signaling via TLS, and > that's what sips means to me. I think that is a useful mechanism, if it > really means TLS end to end. I don't think it's very useful if all it means > is one arc of UAC to UAS if the actual call has two or three such arcs > joined by B2BUAs, or one end is a PSTN connection. > > There may be some yet to be defined security mechanism that allows a more > nuanced expression of what is acceptable, and what was accomplished, but > that's not sips, at least in my opinion. > >> We lack a mechanism for the PSTN gateway to say "it's >> secured up to me, and I'm the last hop and I can't >> make the PSTN do SIPS, sorry." We only have a >> mechanism for the PSTN gateway to say "I can't do SIPS". > Yes, I agree, but that is just the same, to me, as a proxy that can't do TLS > downstream, or a B2BUA that can't do TLS downstream. I don't care WHY they > can't maintain secure signaling connections via TLS end to end, I just know > they can't. That's what I want to know; my signaling is protected end to > end via a hop by hop TLS mechanism. > > 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 Tue Oct 31 11:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewZ5-0004sG-AS; Tue, 31 Oct 2006 11:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewZ2-0004rL-P6 for sip@ietf.org; Tue, 31 Oct 2006 11:34:12 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewYj-0001nM-Lf for sip@ietf.org; Tue, 31 Oct 2006 11:34:12 -0500 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 k9VGXn729102; Tue, 31 Oct 2006 11:33:49 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:33:42 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC994D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3021F282F@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb8V8eJg0q75zb6RA22y84zio7CLAAAhsOwACpThAAAAZT94A== From: "Francois Audet" To: "Michael Hammer \(mhammer\)" , "Paul Kyzivat \(pkyzivat\)" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Tuesday, October 31, 2006 7:48 AM > To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat);=20 > Elwell, John > Cc: IETF SIP List > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > Francois, >=20 > The problem is that the Web has set a precedent for what is=20 > expected of a "secure" Internet service. >=20 > Using httpS means secure request; lock icon means it was accomplished. >=20 > If user sees address sips, they will expect the same. =20 >=20 > What will they think if no icon appears? > What will they think if an icon appears? >=20 > Both, cases indicate the inconsistency with https. Best to=20 > start over from square 1. Euh, no it ain't. We can't deprecate RFC 3261.=20 There are many things that aren't that great in RFC 3261, and we are not deprecating it. Like it or not RFC 3261 is now commercial. It doens't matter what a bunch of technies like us think, we can't just pull the carpet from under it for architecture purity's sake. SIPS is just one of them. Like UDP transport, forking proxies, early media, ambiguity of offer/answer, pre-conditions, SDP in itself, PRACK, UPDATE, Contacts, the RTCP=3DRTP+1 rule, bizarre case-sensitivity rules, strict routing, etc. etc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 11:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewYn-0004p7-IX; Tue, 31 Oct 2006 11:33:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewYl-0004oY-Az for sip@ietf.org; Tue, 31 Oct 2006 11:33:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewYb-0001m3-04 for sip@ietf.org; Tue, 31 Oct 2006 11:33:55 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 08:33:45 -0800 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 k9VGXiiB005709; Tue, 31 Oct 2006 11:33:44 -0500 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 k9VGXiDM028600; Tue, 31 Oct 2006 11:33:44 -0500 (EST) 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, 31 Oct 2006 11:33:44 -0500 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 11:33:44 -0500 Message-ID: <45477AE6.8000109@cisco.com> Date: Tue, 31 Oct 2006 11:33:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Rosen Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> In-Reply-To: <000501c6fc97$eebdb870$d529fea9@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 16:33:44.0322 (UTC) FILETIME=[54F10620:01C6FD0A] DKIM-Signature: a=rsa-sha1; q=dns; l=2603; t=1162312424; x=1163176424; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning) |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3Dr0kv6ZvsYOsda2FiXktGBPaN+fc=3D; b=ID5Xib1g92xW641GqDktEOgkg07/4rnGhcZoSb+CqVn7TQSmfWZOZTdbkblkeLOwmZcIsOzu hZeyaXTh8QRagtx3mnzq+u4Hb3e28y7LwXZOpSB6jo/dsproj2UbnywJ; 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: "'Joel M. Halpern'" , 'IETF SIP List' , '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 Brian, With your expectation about the meaning of SIPS, what is your attitude about TLS offloaders? The link from the offloader to the server isn't TLS. Does that mean a server using an offloader can't support SIPS? Paul Brian Rosen wrote: >>> is the correct interpretation. Similarly, if one end is on >>> the PSTN, then >>> you don't have TLS from end to end. >> According to RFC3261, I do -- the SIP endpoint is that PSTN >> gateway. >> >> With your argument, that PSTN gateway would have to reject >> the SIPS call setup attempt, the originator would have to >> send it via SIP, and possibly expose their signaling and >> media to IP-based eavesdroppers (RFC4568 requires using >> SIPS or S/MIME to protect the key in SDP), just because >> the last hop was the PSTN. > Yes, I agree that's what you would have to do, which would be the same > circumstance if the first hop, which may very well be in a domain that you > can trust can't handle TLS. > > This mechanism IS NOT EVERYTHING WE WISH IT COULD BE, but it's useful. > I think we need to be fairly practical, and I also think we need to think > about what it means to the system as a whole, and not JUST the UAC to UAS > connection. If the signaling is not protected end to end, then it's not > "protected" and saying that a piece of it is protected is not interesting to > anyone. You might as well say that there was at least one hop which was > protected. I feel that the PSTN is not protected signaling via TLS, and > that's what sips means to me. I think that is a useful mechanism, if it > really means TLS end to end. I don't think it's very useful if all it means > is one arc of UAC to UAS if the actual call has two or three such arcs > joined by B2BUAs, or one end is a PSTN connection. > > There may be some yet to be defined security mechanism that allows a more > nuanced expression of what is acceptable, and what was accomplished, but > that's not sips, at least in my opinion. > >> We lack a mechanism for the PSTN gateway to say "it's >> secured up to me, and I'm the last hop and I can't >> make the PSTN do SIPS, sorry." We only have a >> mechanism for the PSTN gateway to say "I can't do SIPS". > Yes, I agree, but that is just the same, to me, as a proxy that can't do TLS > downstream, or a B2BUA that can't do TLS downstream. I don't care WHY they > can't maintain secure signaling connections via TLS end to end, I just know > they can't. That's what I want to know; my signaling is protected end to > end via a hop by hop TLS mechanism. > > 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 Tue Oct 31 11:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewjb-0004WW-53; Tue, 31 Oct 2006 11:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GewjY-0004WK-2K for sip@ietf.org; Tue, 31 Oct 2006 11:45:04 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GewjT-0003gn-Ne for sip@ietf.org; Tue, 31 Oct 2006 11:45:04 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VFmX1i012008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 09:48:34 -0600 In-Reply-To: <7.0.1.0.0.20061031071800.034d6f50@stevecrocker.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> <09C8234F-2946-4C48-854C-5CF5F4EEEF0E@softarmor.com> <7.0.1.0.0.20061031071800.034d6f50@stevecrocker.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89CE38BD-EB0C-47B9-8429-E5A31AEF0090@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:44:56 -0600 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Oct 31, 2006, at 6:20 AM, Joel M. Halpern wrote: > While we currently have the ability to demand security, we actually > have no way to reliably know whether we got it. > If we can not tell if it is being delivered, why is being able to > ask for it better than expecting the system to always deliver it? > > I've been told it comes down to trust. You just don't use sips: to talk to a proxy you don't trust to do the right thing. Common SIP deployment scenarios posit a high level of trust between user and "home" or "outbound" proxy in many other ways. It is no great leap to assume that a proxy you are trusting in all these other ways will, if asked nicely, honor your request for "secure" treatment. If you can't trust a proxy to do this for you, there's all sorts of other stuff you can't trust it to do, and you probably shouldn't be using it as a home or outbound proxy in a conventional SIP deployment. I've been proposing changing SIP so that many of these assumptions are no longer required, but in the absence of those changes, one could reasonably argue that sips: is as strong as the rest of the security model, because it's based on exactly the same trust assumptions. Personally I take that more as an argument against the current SIP security model than as an argument for the strength of sips:, but one could work with it either way. > PS: Just to be clear, the reason i say you can not tell if you got > security is that even if we added extra recordings about what > happens, I am pretty sure that two colluding proxies (such as a > pair that have chosen to use IPSec instead of TLS, or have an old > style telephony view and just trust their network and peering) will > flat lie in order to deliver what they think is the service. Yep. That's a point a I think I've been asserting for quite some time. -- 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 Oct 31 11:47:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewki-0004fy-DF; Tue, 31 Oct 2006 11:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewkf-0004fl-EW for sip@ietf.org; Tue, 31 Oct 2006 11:46:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewke-0003uF-5C for sip@ietf.org; Tue, 31 Oct 2006 11:46:13 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Oct 2006 08:46:11 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VGkBIm005746; Tue, 31 Oct 2006 08:46:11 -0800 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 k9VGkBin026586; Tue, 31 Oct 2006 08:46:11 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn7-379.cisco.com [10.21.145.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VGXMbi016263; Tue, 31 Oct 2006 08:33:23 -0800 Message-ID: <45477DD6.7080704@cisco.com> Date: Tue, 31 Oct 2006 08:46:14 -0800 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: Francois Audet Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) References: <1ECE0EB50388174790F9694F77522CCF0DC994D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC994D7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1315; t=1162313171; x=1163177171; c=relaxed/simple; s=sjdkim1002; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20meaning); X=v=3Dcisco.com=3B=20h=3DGRW9K/sCSuDWaouFDQAw+1n+V/c=3D; b=VE/2XcVNAc+74/zMpemXXNiBMWR58dVRf5j9uNQmT3RUiSS12WEnoxg7nL7NQhWTEdZV9cqj iyopga5TrjpgZPtLdyGJkENodNZXZT6CU3Yxdt3ucbbOciyTOHZ4nLsp; X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List , "Paul Kyzivat \(pkyzivat\)" , "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 Francois Audet wrote: >>-----Original Message----- >>From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] >>Sent: Tuesday, October 31, 2006 7:48 AM >>To: Audet, Francois (SC100:3055); Paul Kyzivat (pkyzivat); >>Elwell, John >>Cc: IETF SIP List >>Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: >>TLS meaning) >> >>Francois, >> >>The problem is that the Web has set a precedent for what is >>expected of a "secure" Internet service. >> >>Using httpS means secure request; lock icon means it was accomplished. >> >>If user sees address sips, they will expect the same. >> >>What will they think if no icon appears? >>What will they think if an icon appears? >> >>Both, cases indicate the inconsistency with https. Best to >>start over from square 1. >> >> > >Euh, no it ain't. > >We can't deprecate RFC 3261. > > This is simply not true. All that it takes to deprecate SIPS: is to make its semantics the same as SIP: on the receiver. As a practical matter, there is nothing that the non-deprecation camp can do about that either. Assuming that this log jam surrounding SIPS eventually leads to better mechanisms, a concerned sender would even have the motivation to implement them if they know that SIPS is a dead letter. 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 Tue Oct 31 11:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewm5-0005Zz-9A; Tue, 31 Oct 2006 11:47:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewm2-0005ZA-8B for sip@ietf.org; Tue, 31 Oct 2006 11:47:38 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewm0-0004CZ-Un for sip@ietf.org; Tue, 31 Oct 2006 11:47:38 -0500 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 k9VGlX702427; Tue, 31 Oct 2006 11:47:33 -0500 (EST) 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: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:47:32 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC99532@zrc2hxm0.corp.nortel.com> In-Reply-To: <17735.6053.182282.83440@harjus.tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Thread-Index: Acb80QXCpka7QQcxSzmKM29TFlxs/QAOAbRw From: "Francois Audet" To: "Juha Heinanen" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Joel M. Halpern" , 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 =20 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Tuesday, October 31, 2006 1:30 AM > To: Elwell, John > Cc: Joel M. Halpern; 'IETF SIP List' > Subject: RE: What controls the lock icon? (Was RE: [Sip] RE:=20 > TLS meaning) >=20 > Elwell, John writes: >=20 > > TLS is not available. So a SIPS request would get=20 > rejected. Now this is fine > if the caller is interested in=20 > making the call only if it can be a secure > call (whatever=20 > that means), but in many cases the caller would want to >=20 > accept an insecure call and the UAC would have to try again=20 > with > SIP.=20 >=20 > i don't think that signaling security alone without media=20 > security means anything to common users. this is further=20 > justification of dropping sips. That is absolute rubish. There are cases where you want signalling to be secure (for authentication, impersonation, theft of service, etc.), but you don't need, or want, or even can have encrypted media. > > So in > > this case, just doing best effort and notifying the UAC=20 > (and perhaps also > the UAS) would be sufficient. The point=20 > is, how often does a UAC require TLS > or nothing, as=20 > opposed to best effort TLS? And how often do proxies route >=20 > SIP requests over TCP or UDP even though TLS would be=20 > available to SIPS > requests? >=20 > it would make sense to always use tls out as long as the next=20 > hop supports it. there is no need for sips to tell that to the proxy. And how do you tell it "do not complete the session if the next hop doesn't support TLS"? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 11:54:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewpj-0006uQ-Af; Tue, 31 Oct 2006 11:51:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewph-0006u6-HZ for sip@ietf.org; Tue, 31 Oct 2006 11:51:25 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewpc-0004tF-Kn for sip@ietf.org; Tue, 31 Oct 2006 11:51:25 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VFspM0012073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 09:54:53 -0600 In-Reply-To: <454761E4.8030207@cisco.com> References: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> <17735.6053.182282.83440@harjus.tutpro.com> <454761E4.8030207@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6205D258-12AB-42FD-9986-186E74901246@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning)) Date: Tue, 31 Oct 2006 10:51:07 -0600 To: Michael Thomas X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Joel M. Halpern" , 'IETF SIP List' , Juha Heinanen , "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 On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > My advise to the working group is to just start over from first > principles as if > SIPS didn't even exist -- which in reality it doesn't. We need to > be thinking > about these things for the long term, and if it's not baked it's > not baked. There > have been many drafts that have lingered on and completely > overhauled over > the years. Why SIPS is treated so differently in that respect is > somewhat > mystifying because dealing with security for SIP is a genuinely > hard problem. > It shouldn't be rushed, and it deserves better than a kludgey > security patina > airbrushed in to get past the IESG. I'm very tempted to endorse this, but I think you're missing one thing. Flimsy as it is, I believe that sips: is as strong as the rest of the current SIP security model since it depends on the same trust assumptions. We can't just restart on sips: without restarting from those fundamental trust assumptions. This is not trivial. Many people would argue that it would turn SIP into a fundamentally different protocol. I think it needs to be done, but I also think we need to clearly document how the current trust model (including sips:) works, because that's what's going to be deployed in the real world for a relatively long time. The P2PSIP work is having to re-examine those fundamental trust assumptions. My current hope is we can do some work there that can be "ported back" into 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 Tue Oct 31 11:59:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewvy-00024e-Mb; Tue, 31 Oct 2006 11:57:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gewvv-00020Z-ID for sip@ietf.org; Tue, 31 Oct 2006 11:57:52 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gewvu-0005vN-99 for sip@ietf.org; Tue, 31 Oct 2006 11:57:51 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VG1K7C012124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 10:01:20 -0600 In-Reply-To: <012e01c6fd00$0e6c6550$c5f0200a@amer.cisco.com> References: <012e01c6fd00$0e6c6550$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5D085398-6A03-4185-A7B3-44969A1CFAF9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:57:42 -0600 To: Dan Wing X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "'Joel M. Halpern'" , '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 Oct 31, 2006, at 9:20 AM, Dan Wing wrote: > > Right. What doesn't make sense, to me, is that we can only > express a binary value. For example, when I'm at a coffeeshop > using their WiFi, I don't want to have to downgrade my > connection to my proxy to SIP (from SIPS) just because I'm > calling the PSTN. > That's why I keep saying this looks like a caller-preferences or Proxy-Require problem problem, not a URI scheme problem. You could get what you want in the above case by having a Proxy- Require: TLS, where this forces any proxy in the loop to use TLS in and out. A Require: TLS might actually transit SBCs, by requiring any UA in the loop to use TLS for induced requests. >>> We lack a mechanism for the PSTN gateway to say "it's >>> secured up to me, and I'm the last hop and I can't >>> make the PSTN do SIPS, sorry." We only have a >>> mechanism for the PSTN gateway to say "I can't do SIPS". >> >> Yes, I agree, but that is just the same, to me, as a proxy >> that can't do TLS >> downstream, or a B2BUA that can't do TLS downstream. I don't >> care WHY they >> can't maintain secure signaling connections via TLS end to >> end, I just know >> they can't. That's what I want to know; my signaling is >> protected end to >> end via a hop by hop TLS mechanism. > > I am interested in working on a mechanism that allows > signaling that condition. Would the Require and Proxy-Require I roughly describe above address you concerns? -- 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 Oct 31 12:13:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex9U-00020D-Cp; Tue, 31 Oct 2006 12:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex9S-000208-Ik for sip@ietf.org; Tue, 31 Oct 2006 12:11:50 -0500 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 1Gex9O-0002Bn-8w for sip@ietf.org; Tue, 31 Oct 2006 12:11:50 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id A3BC0794; Tue, 31 Oct 2006 12:11:24 -0500 From: "Hadriel Kaplan" To: "'Michael Thomas'" Subject: RE: [Sip] SIPS: why not S/MIME instead? Date: Tue, 31 Oct 2006 12:11:24 -0500 Message-ID: <00b201c6fd0f$9822ebc0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9Aha+zL0kjmpXTei6HpR7QwthBAABzR+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45476D16.6020605@cisco.com> X-Spam-Score: 0.1 (/) 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 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, October 31, 2006 10:35 AM > > Note first that I'm not trying to make light of the difficulties of S/MIME > usage (which is largely the enrollment problem as you point out). But if > SIPS is really supposed to be TLS to either to the UAS or a proxy one > up from the UAS, aren't you left with the exact same enrollment problem > regardless of whether it's TLS or S/MIME? Nope - with the current model, the final UAS doesn't need a cert at all - it's TLS connection would already be up from it registering and verifying the proxy's/registrar's cert, and the proxy/reg verifying the UAS with digest over the TLS connection. Ergo why some think outbound will be the panacea, as no (final) UAx would need to have a cert. > Thus it seems to me that if > all other things are equal, wouldn't you rather choose the one that at > least eliminates the MITM attack inherent with hopwise TLS? Would > it be a satisfactory state of affairs that S/MIME and/or e2e security was > impossible because of these record-routing proxies and b2bua's? I > sure hope not. We can't have our cake and eat it too. :) If none of the boxes in the middle need to be in the signaling path, then one wonders why they are there. Location finding alone can't require so many hops. But the truth is they do a lot more than finding the location of the UAS. Some of what they do is unpalatable to the IETF, but the market decides those things, not the IETF. Even the notion of e2e security's value is seen differently by some people. You think the UA on your PC or desk-phone is more secure than the middle-boxes. I assure you the owners/operators of the middle-boxes feel the exact opposite way. -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 Oct 31 12:18:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexDj-00039W-Aw; Tue, 31 Oct 2006 12:16:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexDg-00038f-I5 for sip@ietf.org; Tue, 31 Oct 2006 12:16:12 -0500 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 1GexDc-0003Hx-7I for sip@ietf.org; Tue, 31 Oct 2006 12:16:12 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 Oct 2006 09:16:08 -0800 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 k9VHG4vC003298; Tue, 31 Oct 2006 09:16:07 -0800 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 k9VHG4W4005089; Tue, 31 Oct 2006 09:16:04 -0800 (PST) Received: from [216.102.208.13] (sjc-vpn7-379.cisco.com [10.21.145.123]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9VH38Je016925; Tue, 31 Oct 2006 09:03:11 -0800 Message-ID: <454784CF.3040602@cisco.com> Date: Tue, 31 Oct 2006 09:15:59 -0800 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: <50B1CBA96870A34799A506B2313F26670A3D7980@ntht201e.siemenscomms.co.uk> <17735.6053.182282.83440@harjus.tutpro.com> <454761E4.8030207@cisco.com> <6205D258-12AB-42FD-9986-186E74901246@softarmor.com> In-Reply-To: <6205D258-12AB-42FD-9986-186E74901246@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2345; t=1162314967; x=1163178967; c=relaxed/simple; s=sjdkim3002; 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=20What=20consensus?; X=v=3Dcisco.com=3B=20h=3DTT3vnxBbLhcL+1v6B+S/gOLf8zc=3D; b=nmNY2686H7KV2b603S59genM7FqkWQzBTbDc8cce96Eh5MFto3XAkfHPfJ7pvcfT8C9m2UFo hT+3Us8GRBURFRQd+lg65LO9/pQsN4PBIaBhpl1T2pO5YJTtcS+jRRN6; X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Joel M. Halpern" , 'IETF SIP List' , Juha Heinanen , "Elwell, John" Subject: [Sip] Re: What consensus? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Oct 31, 2006, at 8:47 AM, Michael Thomas wrote: > >> My advise to the working group is to just start over from first >> principles as if >> SIPS didn't even exist -- which in reality it doesn't. We need to be >> thinking >> about these things for the long term, and if it's not baked it's not >> baked. There >> have been many drafts that have lingered on and completely >> overhauled over >> the years. Why SIPS is treated so differently in that respect is >> somewhat >> mystifying because dealing with security for SIP is a genuinely hard >> problem. >> It shouldn't be rushed, and it deserves better than a kludgey >> security patina >> airbrushed in to get past the IESG. > > > I'm very tempted to endorse this, but I think you're missing one thing. > > Flimsy as it is, I believe that sips: is as strong as the rest of the > current SIP security model since it depends on the same trust > assumptions. I would say that just allowing hopwise TLS is as good as the current SIP security model. SIPS tries to *extend* the current SIP security model into something that it is not. Where SIPoTLS is overall neutral to good for the long term, SIPS actively goes in the wrong direction, and promises something that it cannot deliver. And thus we're getting all kinds of bizarre interpretations of what SIPS is, one a little more whacky than the next. And who can argue? I find Brian's interpretation aesthetically unappealing and unlikely to be of any practical use, but it's at least got internal consistency. Which rather begs the question of what exactly we're trying to accomplish here. Mike > > We can't just restart on sips: without restarting from those > fundamental trust assumptions. > > This is not trivial. Many people would argue that it would turn SIP > into a fundamentally different protocol. I think it needs to be done, > but I also think we need to clearly document how the current trust > model (including sips:) works, because that's what's going to be > deployed in the real world for a relatively long time. > > The P2PSIP work is having to re-examine those fundamental trust > assumptions. My current hope is we can do some work there that can be > "ported back" into 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 Tue Oct 31 13:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexvM-0006Cq-2M; Tue, 31 Oct 2006 13:01:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexut-0005ma-Fc for sip@ietf.org; Tue, 31 Oct 2006 13:00:51 -0500 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 1Gexku-0006Bh-Hw for sip@ietf.org; Tue, 31 Oct 2006 12:50:36 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id ACBC0728; Tue, 31 Oct 2006 12:49:48 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Joel M. Halpern'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 12:49:47 -0500 Message-ID: <00bf01c6fd14$f58ab7c0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9DCilJfCfXuCNTM+bGwzeesbDbQACIevA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <89CE38BD-EB0C-47B9-8429-E5A31AEF0090@softarmor.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 So if we're going to trust the proxies, why don't we trust them to decide what is "secure", instead of mandating TLS? I mean why would you trust them to implement the tls profile correctly, follow 3261 and Francois' clarity-draft, not downgrade, etc., but not trust them to implement IPSec correctly? If the proxy decides the next-hop is secure, and the next-hop proxy decides it's previous-hop is secure, why is that not enough? -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, October 31, 2006 11:45 AM > To: Joel M. Halpern > Cc: 'IETF SIP List' > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) > > > On Oct 31, 2006, at 6:20 AM, Joel M. Halpern wrote: > > > While we currently have the ability to demand security, we actually > > have no way to reliably know whether we got it. > > If we can not tell if it is being delivered, why is being able to > > ask for it better than expecting the system to always deliver it? > > > > > > I've been told it comes down to trust. You just don't use sips: to > talk to a proxy you don't trust to do the right thing. > > Common SIP deployment scenarios posit a high level of trust between > user and "home" or "outbound" proxy in many other ways. It is no > great leap to assume that a proxy you are trusting in all these other > ways will, if asked nicely, honor your request for "secure" > treatment. If you can't trust a proxy to do this for you, there's all > sorts of other stuff you can't trust it to do, and you probably > shouldn't be using it as a home or outbound proxy in a conventional > SIP deployment. > > I've been proposing changing SIP so that many of these assumptions > are no longer required, but in the absence of those changes, one > could reasonably argue that sips: is as strong as the rest of the > security model, because it's based on exactly the same trust > assumptions. Personally I take that more as an argument against the > current SIP security model than as an argument for the strength of > sips:, but one could work with it either way. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexvd-0006j2-9G; Tue, 31 Oct 2006 13:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexuX-0005Pf-Ug for sip@ietf.org; Tue, 31 Oct 2006 13:00:30 -0500 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GexpV-0007Ms-MT for sip@ietf.org; Tue, 31 Oct 2006 12:55:24 -0500 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 31 Oct 2006 09:55:16 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9VHqZvV010533; Tue, 31 Oct 2006 09:52:39 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9VHt6PF022427; Tue, 31 Oct 2006 09:55:07 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:55:06 -0800 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] SIPS: why not S/MIME instead? Date: Tue, 31 Oct 2006 09:54:27 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141299@namail5.corp.adobe.com> In-Reply-To: <45476D16.6020605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPS: why not S/MIME instead? Thread-Index: Acb9AoUAebm2UtjuS0+1YI3tpX6pawAEeabA From: "Henry Sinnreich" To: "Michael Thomas" , "Hadriel Kaplan" X-OriginalArrivalTime: 31 Oct 2006 17:55:06.0634 (UTC) FILETIME=[B306B6A0:01C6FD15] X-Spam-Score: 0.0 (/) 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 Michael Thomas wrote: > Would it be a satisfactory state of affairs that S/MIME and/or e2e=20 > security was impossible because of these record-routing proxies and=20 > b2bua's? I sure hope not. Please don't hope, since it's exactly as you say: e2e security is impossible with record routing proxies and B2BUA' since no one knows if they may be compromised or accessible to some bad employee, etc. These intermediaries are just MITM attacks waiting to happen. Thanks, Henry -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com]=20 Sent: Tuesday, October 31, 2006 9:35 AM To: Hadriel Kaplan Cc: 'IETF SIP List' Subject: Re: [Sip] SIPS: why not S/MIME instead? Hadriel Kaplan wrote: > =20 > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Monday, October 30, 2006 12:12 PM >> >>As an alternative of my previous proposal, there seems to be quite a bit >>of >>unhappiness of the general bogosity of the last hop (UAS) exception of >>SIPS. >>If we remove that restriction, I guess I have to ask the question if you >>want integrity/confidentiality along the path where you ultimately have no >>real control over the transport chosen by middle proxies -- why don't >>you just >>get/learn the cert of the intended party and use S/MIME which actually >>give >>you the security properties that you're most likely hoping for with SIPS? >> =20 >> > >Because UA's rarely have certificates, or ones worth trusting. And because >to get that cert you would have had to have contacted the UAS using a >signaling protocol (ie, SIP), so you've already done it. Even if you make >it an options request or something benign, "they'll know". And then S/MIME >is only a body and the message headers say a lot already - even if you have >the sip headers copied+signed+encrypted in the s/mime body, they're in the >clear in the message. So you'll want to encrypt+auth the whole sip message >not just the body. >And honestly there's probably a reason so many proxies are record-routing, >or being b2bua's. Trying to bypass them is a Sysiphean task. > =20 > Note first that I'm not trying to make light of the difficulties of S/MIME usage (which is largely the enrollment problem as you point out). But if SIPS is really supposed to be TLS to either to the UAS or a proxy one up from the UAS, aren't you left with the exact same enrollment problem regardless of whether it's TLS or S/MIME? Thus it seems to me that if all other things are equal, wouldn't you rather choose the one that at least eliminates the MITM attack inherent with hopwise TLS? Would it be a satisfactory state of affairs that S/MIME and/or e2e security was impossible because of these record-routing proxies and b2bua's? I sure hope not. >>Which isn't to say that TLS is not useful, but SIPS is trying to >>approximate >>what S/MIME gets you, so it's not clear why you shouldn't we shouldn't >>be promoting it instead of the obvious hack that SIPS is. >> =20 >> > >Because S/MIME has been even less successful than SIPS (if that's possible). > =20 > Beyond the enrollment problem, the same place you get TLS API's gets you S/MIME API's as well (openssl). So that's probably not the problem. Note that I'm not suggesting that S/MIME needs to necessarily be UAC to UAS. I've always thought that these things need to be though of in terms of "trust point" to "trust point", where "trust point" is whatever gives me comfort. A middle to middle that allows you to fly over dangerous territory may be exactly the right thing in many cases. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexvM-0006Cq-2M; Tue, 31 Oct 2006 13:01:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexut-0005ma-Fc for sip@ietf.org; Tue, 31 Oct 2006 13:00:51 -0500 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 1Gexku-0006Bh-Hw for sip@ietf.org; Tue, 31 Oct 2006 12:50:36 -0500 Received: from hkaplan [10.0.200.156] by acmepacket.com with ESMTP (SMTPD-9.10) id ACBC0728; Tue, 31 Oct 2006 12:49:48 -0500 From: "Hadriel Kaplan" To: "'Dean Willis'" , "'Joel M. Halpern'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 12:49:47 -0500 Message-ID: <00bf01c6fd14$f58ab7c0$0500a8c0@acmepacket.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb9DCilJfCfXuCNTM+bGwzeesbDbQACIevA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <89CE38BD-EB0C-47B9-8429-E5A31AEF0090@softarmor.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 So if we're going to trust the proxies, why don't we trust them to decide what is "secure", instead of mandating TLS? I mean why would you trust them to implement the tls profile correctly, follow 3261 and Francois' clarity-draft, not downgrade, etc., but not trust them to implement IPSec correctly? If the proxy decides the next-hop is secure, and the next-hop proxy decides it's previous-hop is secure, why is that not enough? -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, October 31, 2006 11:45 AM > To: Joel M. Halpern > Cc: 'IETF SIP List' > Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) > > > On Oct 31, 2006, at 6:20 AM, Joel M. Halpern wrote: > > > While we currently have the ability to demand security, we actually > > have no way to reliably know whether we got it. > > If we can not tell if it is being delivered, why is being able to > > ask for it better than expecting the system to always deliver it? > > > > > > I've been told it comes down to trust. You just don't use sips: to > talk to a proxy you don't trust to do the right thing. > > Common SIP deployment scenarios posit a high level of trust between > user and "home" or "outbound" proxy in many other ways. It is no > great leap to assume that a proxy you are trusting in all these other > ways will, if asked nicely, honor your request for "secure" > treatment. If you can't trust a proxy to do this for you, there's all > sorts of other stuff you can't trust it to do, and you probably > shouldn't be using it as a home or outbound proxy in a conventional > SIP deployment. > > I've been proposing changing SIP so that many of these assumptions > are no longer required, but in the absence of those changes, one > could reasonably argue that sips: is as strong as the rest of the > security model, because it's based on exactly the same trust > assumptions. Personally I take that more as an argument against the > current SIP security model than as an argument for the strength of > sips:, but one could work with it either way. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexvd-0006j2-9G; Tue, 31 Oct 2006 13:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexuX-0005Pf-Ug for sip@ietf.org; Tue, 31 Oct 2006 13:00:30 -0500 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GexpV-0007Ms-MT for sip@ietf.org; Tue, 31 Oct 2006 12:55:24 -0500 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 31 Oct 2006 09:55:16 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9VHqZvV010533; Tue, 31 Oct 2006 09:52:39 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9VHt6PF022427; Tue, 31 Oct 2006 09:55:07 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 09:55:06 -0800 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] SIPS: why not S/MIME instead? Date: Tue, 31 Oct 2006 09:54:27 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141299@namail5.corp.adobe.com> In-Reply-To: <45476D16.6020605@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPS: why not S/MIME instead? Thread-Index: Acb9AoUAebm2UtjuS0+1YI3tpX6pawAEeabA From: "Henry Sinnreich" To: "Michael Thomas" , "Hadriel Kaplan" X-OriginalArrivalTime: 31 Oct 2006 17:55:06.0634 (UTC) FILETIME=[B306B6A0:01C6FD15] X-Spam-Score: 0.0 (/) 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 Michael Thomas wrote: > Would it be a satisfactory state of affairs that S/MIME and/or e2e=20 > security was impossible because of these record-routing proxies and=20 > b2bua's? I sure hope not. Please don't hope, since it's exactly as you say: e2e security is impossible with record routing proxies and B2BUA' since no one knows if they may be compromised or accessible to some bad employee, etc. These intermediaries are just MITM attacks waiting to happen. Thanks, Henry -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com]=20 Sent: Tuesday, October 31, 2006 9:35 AM To: Hadriel Kaplan Cc: 'IETF SIP List' Subject: Re: [Sip] SIPS: why not S/MIME instead? Hadriel Kaplan wrote: > =20 > >>-----Original Message----- >>From: Michael Thomas [mailto:mat@cisco.com] >>Sent: Monday, October 30, 2006 12:12 PM >> >>As an alternative of my previous proposal, there seems to be quite a bit >>of >>unhappiness of the general bogosity of the last hop (UAS) exception of >>SIPS. >>If we remove that restriction, I guess I have to ask the question if you >>want integrity/confidentiality along the path where you ultimately have no >>real control over the transport chosen by middle proxies -- why don't >>you just >>get/learn the cert of the intended party and use S/MIME which actually >>give >>you the security properties that you're most likely hoping for with SIPS? >> =20 >> > >Because UA's rarely have certificates, or ones worth trusting. And because >to get that cert you would have had to have contacted the UAS using a >signaling protocol (ie, SIP), so you've already done it. Even if you make >it an options request or something benign, "they'll know". And then S/MIME >is only a body and the message headers say a lot already - even if you have >the sip headers copied+signed+encrypted in the s/mime body, they're in the >clear in the message. So you'll want to encrypt+auth the whole sip message >not just the body. >And honestly there's probably a reason so many proxies are record-routing, >or being b2bua's. Trying to bypass them is a Sysiphean task. > =20 > Note first that I'm not trying to make light of the difficulties of S/MIME usage (which is largely the enrollment problem as you point out). But if SIPS is really supposed to be TLS to either to the UAS or a proxy one up from the UAS, aren't you left with the exact same enrollment problem regardless of whether it's TLS or S/MIME? Thus it seems to me that if all other things are equal, wouldn't you rather choose the one that at least eliminates the MITM attack inherent with hopwise TLS? Would it be a satisfactory state of affairs that S/MIME and/or e2e security was impossible because of these record-routing proxies and b2bua's? I sure hope not. >>Which isn't to say that TLS is not useful, but SIPS is trying to >>approximate >>what S/MIME gets you, so it's not clear why you shouldn't we shouldn't >>be promoting it instead of the obvious hack that SIPS is. >> =20 >> > >Because S/MIME has been even less successful than SIPS (if that's possible). > =20 > Beyond the enrollment problem, the same place you get TLS API's gets you S/MIME API's as well (openssl). So that's probably not the problem. Note that I'm not suggesting that S/MIME needs to necessarily be UAC to UAS. I've always thought that these things need to be though of in terms of "trust point" to "trust point", where "trust point" is whatever gives me comfort. A middle to middle that allows you to fly over dangerous territory may be exactly the right thing in many cases. 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:04:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GexwJ-0007Np-Or; Tue, 31 Oct 2006 13:02:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gexuz-0005vM-Ur for sip@ietf.org; Tue, 31 Oct 2006 13:00:58 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GexjF-0005gq-Mc for sip@ietf.org; Tue, 31 Oct 2006 12:48:55 -0500 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 k9VHmXX10793; Tue, 31 Oct 2006 12:48:33 -0500 (EST) 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] Re: What consensus? Date: Tue, 31 Oct 2006 11:48:32 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC996EF@zrc2hxm0.corp.nortel.com> In-Reply-To: <454784CF.3040602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: What consensus? Thread-Index: Acb9EK90rikDA7fqS8eOEgv2sfA3yQAAGVAA From: "Francois Audet" To: "Michael Thomas" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Joel M. Halpern" , IETF SIP List , Juha Heinanen , "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 > I would say that just allowing hopwise TLS is as good as the=20 > current SIP security model. SIPS tries to *extend* the=20 > current SIP security model into something that it is not.=20 > Where SIPoTLS is overall neutral to good for the long term,=20 > SIPS actively goes in the wrong direction, and promises=20 > something that it cannot deliver. And thus we're getting all=20 > kinds of bizarre interpretations of what SIPS is, one a=20 > little more whacky than the next. This is I believe why we are having such a hard time with sips. The problem is that you (and others) are giving to sips more ambition than it actually should have. - SIPS is NOT and indication end-to-end "security" (whatever that means). SIPS does NOT imply a padlock icon. - Using SIPS in a request URI does NOT imply that all the hops will be actually end-up being secure. - SIPS does NOT say anything about cyphersuites. The only thing that sips does is allow for extending the SIPoverTLS hop-by-hop (without sips) like this: - Allows for dynamically requesting that a request be sent over TLS on all hops (except the last one unfortunately) and FAIL that request=20 if not possible. (i.e., it is the equivalent to a Proxy-Require: SIP/TLS if that existed). That's it.=20 > And who can argue? I find Brian's interpretation=20 > aesthetically unappealing and unlikely to be of any practical=20 > use, but it's at least got internal consistency. > Which rather begs the question of what exactly we're trying=20 > to accomplish here. We are trying to accomplish 2 things, one short term, and one long term. SHORT TERM: - We need to put a lid on inflated expectations of what SIPS really means. I favor a minimalistic interpretation of what SIPS means. The sooner we=20 close that lid, the sooner we can move on to the LONG TERM. - This interpretation is in line with the spirit of RFC 3261. We are trying first to "explain" RFC 3261, with it's limitations, in order to move on to something more comprehensive.=20 - If SIPS is useful or not in a specific deployment depends on many factors,=20 depending if its a controlled environment, what security properties you are=20 looking for, etc. I don't think it is very productive to second-guess what=20 other people's requirements are. We all have our own specialities, market, etc. - I believe we should follow the directives on that front that came from the chair. =20 LONG TERM: - We need to look at end-to-end security. I completely agree that it probably=20 makes sense to start fresh on this (i.e., to NOT base it on SIPS). - I believe it is very likely that at some point, this will make sips obsolete or or at least quaint and primitive. That's OK too.=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 Oct 31 13:20:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyBY-0001H9-5H; Tue, 31 Oct 2006 13:18:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyBP-0001FV-HE for sip@ietf.org; Tue, 31 Oct 2006 13:17:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyBI-0006kV-1H for sip@ietf.org; Tue, 31 Oct 2006 13:17:55 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 10:17:47 -0800 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 k9VIHlsC017776; Tue, 31 Oct 2006 10:17:47 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VIHlbF006501; Tue, 31 Oct 2006 10:17:47 -0800 (PST) From: "Dan Wing" To: "'Dean Willis'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 10:17:47 -0800 Keywords: direct-to-dwing Message-ID: <03b501c6fd18$de489920$c5f0200a@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: Acb9DbKhIBzU69PBRSKTXMf7F0nkSwACukYQ In-Reply-To: <5D085398-6A03-4185-A7B3-44969A1CFAF9@softarmor.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1809; t=1162318667; x=1163182667; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning); X=v=3Dcisco.com=3B=20h=3D59UMOjsl4qSM1GeKz5v65xpvfWE=3D; b=Xrn5pPQaa+6Vgt7/swfciVDM7wD/0lFgsBZrcyq4ZU4I87wXQCXH2sM7gm9ZaOVZvgoriklH QcegkH1g5nDblY/olantVXdSZkfjdGAx6Pc2I8YTOyng55NELS/UMVH4; 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: 4adaf050708fb13be3316a9eee889caa Cc: "'Joel M. Halpern'" , '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 > > Right. What doesn't make sense, to me, is that we can only > > express a binary value. For example, when I'm at a coffeeshop > > using their WiFi, I don't want to have to downgrade my > > connection to my proxy to SIP (from SIPS) just because I'm > > calling the PSTN. > > > > That's why I keep saying this looks like a caller-preferences or > Proxy-Require problem problem, not a URI scheme problem. > > You could get what you want in the above case by having a Proxy- > Require: TLS, where this forces any proxy in the loop to use TLS in > and out. > > A Require: TLS might actually transit SBCs, by requiring any UA in > the loop to use TLS for induced requests. > > > >>> We lack a mechanism for the PSTN gateway to say "it's > >>> secured up to me, and I'm the last hop and I can't > >>> make the PSTN do SIPS, sorry." We only have a > >>> mechanism for the PSTN gateway to say "I can't do SIPS". > >> > >> Yes, I agree, but that is just the same, to me, as a proxy > >> that can't do TLS > >> downstream, or a B2BUA that can't do TLS downstream. I don't > >> care WHY they > >> can't maintain secure signaling connections via TLS end to > >> end, I just know > >> they can't. That's what I want to know; my signaling is > >> protected end to > >> end via a hop by hop TLS mechanism. > > > > I am interested in working on a mechanism that allows > > signaling that condition. > > Would the Require and Proxy-Require I roughly describe > above address you concerns? They're close. What I'd like is the ability to get TLS everywhere I can, and still allow a call to complete in the event a hop or two couldn't get TLS. With Require, I believe a proxy will not forward the INVITE if it can't provide TLS on that next hop, right? -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 Oct 31 13:20:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyCL-0001Y8-JV; Tue, 31 Oct 2006 13:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyCJ-0001Xj-Dk for sip@ietf.org; Tue, 31 Oct 2006 13:18:51 -0500 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 1GeyCI-00076b-1I for sip@ietf.org; Tue, 31 Oct 2006 13:18:51 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2006 10:18:49 -0800 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 k9VIIn4q031763; Tue, 31 Oct 2006 10:18:49 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9VIIlin025387; Tue, 31 Oct 2006 10:18:47 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Oct 2006 10:18:47 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:18:47 -0800 Message-ID: <45479386.6040704@cisco.com> Date: Tue, 31 Oct 2006 13:18:46 -0500 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: Marc Petit-Huguenin Subject: Re: [Sip] Updated route construct specification References: <4535367D.6030707@cisco.com> <4542A5E7.3050809@acm.org> In-Reply-To: <4542A5E7.3050809@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 18:18:47.0359 (UTC) FILETIME=[01D824F0:01C6FD19] DKIM-Signature: a=rsa-sha1; q=dns; l=2277; t=1162318729; x=1163182729; c=relaxed/simple; s=sjdkim2002; 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=20route=20construct=20specification; X=v=3Dcisco.com=3B=20h=3Dk76Hk+e7sY02P/2wG45P8nNYa7Q=3D; b=VGYIzcNV3GesDf78RWkV76T5g9XH7L/BnwiQZvMLU9WXbx0fGMbWHfIJRqilNyvVIRVfefKK 20jHp6yso6yXJmIZ/BsNU4j07BHJ7GaD8FtEEMoQDaC5uzxzqoNqd5Ms; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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. Sorry this was confusing; it was a consequence of the -00 vs non-00 deadlines, and things changed in my documents between. The whole bit about 305 moved into the loose-routing document: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt and was vastly simplified. In that document, its not a specific response code any more that triggers the behavior. The complicated feature on targeting a redirect to a specific upstream client was removed. Its much simpler now. -Jonathan R. Marc Petit-Huguenin wrote: > Hi Jonathan, > > It seems that the text for the 305 response disappeared between -01 and > -02, but draft-rosenberg-sip-outbound-discovery-mid-dialog-00 is still > using this reference. Is there a plan to move the 305 text to another I-D? > > Thanks. > > Jonathan Rosenberg wrote: > >>I've updated this document. It is (once again) almost completely >>rewritten. Until it appears in the archives, you can pick it up at: >> >>http://www.jdrosen.net/papers/draft-rosenberg-sip-route-construct-02.txt >> >>Basically, it proposes to turn Service-Route into the inverse of Path, >>so that Service-Route/Path work more like record-routing. This is now >>specified in a way which is backwards compatible with IMS, which was an >>issue for the previous spec. I believe this makes service-route usable >>for the internet at large, and it is a key part of solving the >>sip-outbound mid-dialog failover problem. Its also WAY simpler than >>previous versions. The whole bit in there about redirections overriding >>route sets is now folded into the more general UA loose routing document >>I also published. >> >>Just to get some controversy thrown in there, the draft also specifies >>as part of its behavior that a UA register only a single contact at a >>time, and only that contact get reflected in the REGISTER response. >> >>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 Oct 31 13:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyEe-0002ab-FC; Tue, 31 Oct 2006 13:21:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyEa-0002a2-N2 for sip@ietf.org; Tue, 31 Oct 2006 13:21:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyEX-0007xs-5d for sip@ietf.org; Tue, 31 Oct 2006 13:21:12 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VHOhWp012762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 31 Oct 2006 11:24:43 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Tue, 31 Oct 2006 12:21:05 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Sip] A sips: trial balloon for you to shoot down X-BeenThere: sip@ietf.org X-Mailman-Version: 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, let me make a proposal, or perhaps remake one somebody else has made. I've lost track of who said what... I think we're now talking about a BCP for secure operations. 1) Implementations of SIP SHOULD use TLS as described in RFC 3261 for all SIP traffic, including traffic using a sip: URI scheme. Failure to use TLS may result in disclosure of sensitive signaling information to third parties. As a matter of local policy, some deployments MAY use IPSEC or physically protected infrastructure instead of TLS on specific links. Examples where this might be appropriate include persistent IPSEC relationships between proxies within an operational domain and physically protected "private network" cables between a TLS concentrator and the device it is fronting for. Where TLS is not used, the implementor MUST exercise a high level of caution to provide adequate security and MUST preserve operationally equivalent protection of message integrity, privacy, and participant identity (authentication). 2) When using the sips: URI scheme, implementations MUST NOT exercise the "last hop exception" for sips: processing described in RFC 3261. Most scenarios where this technique might have seemed appropriate can be better satisfied using a client-initiated TLS connection as described in draft-ietf-sip-outbound. User agents that do not implement both TLS and either terminate TLS connections or exercise draft-ietf-sip-outbound with a US-originated TOS connection to an outbound will therefore not be able to exercise the sips: URI scheme. Failure to observe this requirement is likely to result in a reduction of operational security below that expected from the sips: URI scheme. 3) Since some user-agents will not be able to exercise the sips: scheme, implementations MUST anticipate the failure of sips: requests and in general SHOULD use sips: only when it is desired that the request will not complete unless TLS will be used on each hop. Since requests using the sip: URI scheme are (by requirement 1 above) expected to be as securely processed as the implementation is able to do, it is not suggested that one first try sips: and then back off to sip:. In other words, if you're willing to settle for the best security that can actually be provided, simply originate the request with a sip: URI scheme. 4) User agent servers that terminate a request using the sips: URI scheme MUST create any dependent requests using the sips: URI scheme. This preserves the commitments of the sips: scheme, and failure to observe this constraint would give the appearance of sips: security where no such security exists. For example, this requirement means that that back-to-back user agents bridging two sips: requests use sips: on both sides. Furthermore, gateways to other protocols not offering equally strong protections MUST NOT exercise the sips: URI scheme. In particular, PSTN gateways MUST NOT use sips:, since the PSTN itself does not offer equivalent protections and there is no ability to determine whether the PSTN segment might be converted back to a sip: request somewhere downstream. -- 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 Oct 31 13:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyGF-0003VT-VU; Tue, 31 Oct 2006 13:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyGE-0003UA-AN for sip@ietf.org; Tue, 31 Oct 2006 13:22:54 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyG8-0008ME-7o for sip@ietf.org; Tue, 31 Oct 2006 13:22:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1302698ugd for ; Tue, 31 Oct 2006 10:22:47 -0800 (PST) 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=Q4C29ZFqLxAQU/ZC5x0fJvI67oWsE+FlOf+kryPQygof8YwtmlsRTbNuLvRVUQAcq959k2PAb/MNi9Mi8hhg2UuXhMsdOrd+MKZrTIJtvn5WDFwNwYUroMQdehPxDLFcNS7YsmayvIHjmaeTVprMNnzhECsAf0itJQw+2vcEg2I= Received: by 10.78.204.1 with SMTP id b1mr7240112hug; Tue, 31 Oct 2006 10:22:46 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 31 Oct 2006 10:22:46 -0800 (PST) Message-ID: <953beacc0610311022j2fb4ef0eh6eb5c3ec6598d9a6@mail.gmail.com> Date: Tue, 31 Oct 2006 10:22:46 -0800 From: "Rohan Mahy" To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] One big concern with outbound-05 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594045492C4@esealmw113.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <089801c6fc69$b57d2100$191e0bc1@it.su.se> <5EB80D22825EEE42872083AD5BFFB594045492C4@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org, 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 Hi, Comments inline. On 10/30/06, Christer Holmberg (JO/LMF) wrote: > > Hi, > > >>I don't think you can assume that the sip-p.net proxies won't add Path > > >>headers. Path is used for other purposes than outbound, so > >>there may be many non-outbound related reasons why proxies add Path. > >> > >>For example, in IMS the P-CSCF could be the edge proxy, but > >>then you can have other intermediate nodes between the P-CSCF and home > S-CSCF > >>(registrar) that insert Path. > > > >My concern was only with not having more proxys than > >necessary adding themselves to the Path vector. > > I understand. But, we can still not make any assumptions on that issue. > > For example, in an IMS roaming scenario you could have 3 entities adding > a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a > home IBCF. My point to Fredrik is that none of these additional intermediaries NEED to add a Path header for the purposes of outbound. If they WANT to add a Path header for some other reason, that is the choice of the network provider. > >I do however see the problem you are talking about with > >Outbound effectively being disabled if there is some other > >proxy on the way between the UA and the registrar that adds > >itself to the Path vector for some non-Outbound reason, and > >not including the ;ob parameter since it doesn't know about > >Outbound. In that case, reachability from the Authoritative > >proxy / registrar to the UA won't be guaranteed. > > > >Changing it to what you suggest, only demand the edge proxy > >closest to the UA to support Outbound, would of course (at > >least slightly) reduce the chance of reachability from the > >Authoritative proxy / registrar to the UA, but at least until > >now I haven't been able to come to any other conclusion than > >that it would probably work often enough (because the edge > >proxys closest to the UA probably will have global reachability)... > >I am looking forward to Rohan's response to this. > > Me too :) Perhaps I am going too far in trying to insure connectivity back to the UA. Today there are some networks that don't require a border signaling element and some that do. The assumption that the border element for foo.com can reach any edge proxy for foo.com pre-dates outbound, but it is kind of brittle. The current outbound draft provides a more reliable assurance of working connectivity, but at the price of requiring more devices in the path to understand outbound. > >When thinking about this I came up with another question : > > > >What if there are NATs between a series of edge proxys > >between the UA and the Authoritative proxy / registrar - who > >is going to keep those connections alive? The UA will keep > >it's connection to the first edge proxy alive using STUN > >keepalives, but who is going to make sure that the flows > >between the edge proxys are still alive? > > I think the assumption is that the non-controllable NAT(s) will only be > located in the "access network", between the UA and the edge proxy. At > least that is the assumption in IMS. We ruled this out of scope for the current outbound draft. There are still folks who want to address this as future work though. thanks, -rohan > I am not sure I understand the concept of multiple edge proxies in the > flow path, but that is a separate issue... > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyLD-0000JO-Fg; Tue, 31 Oct 2006 13:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyL4-0000Hz-77 for sip@ietf.org; Tue, 31 Oct 2006 13:27:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyL1-0001wp-RB for sip@ietf.org; Tue, 31 Oct 2006 13:27:54 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 10:27:51 -0800 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 k9VIRpa7031435; Tue, 31 Oct 2006 10:27:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VIRpOV016908; Tue, 31 Oct 2006 10:27:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:27:50 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 10:27:50 -0800 Message-ID: <454795A5.10000@cisco.com> Date: Tue, 31 Oct 2006 13:27:49 -0500 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] Updated route construct specification References: <5EB80D22825EEE42872083AD5BFFB59404548FE1@esealmw113.eemea.ericsson.se> In-Reply-To: <5EB80D22825EEE42872083AD5BFFB59404548FE1@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2006 18:27:50.0678 (UTC) FILETIME=[45B00B60:01C6FD1A] DKIM-Signature: a=rsa-sha1; q=dns; l=2864; t=1162319271; x=1163183271; 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=20route=20construct=20specification; X=v=3Dcisco.com=3B=20h=3Dk76Hk+e7sY02P/2wG45P8nNYa7Q=3D; b=Vlla5Ndg/TyjLZ9on9dAmkefEDFVVyqNxI0kqgIYR9+S15gziHlswpfoMYUOXHqItD+3UWjT ErHocZ0l1s7P2//0X2h2bjPTTRG7IPXtus95zO/55YB/LQedk+kora60; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@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 Christer Holmberg (JO/LMF) wrote: > Hi, > > Thank you for putting this document together! Some initial comments and > questions. > > My FIRST comment/question is: do we really need the "p2sr" flag? Isn't > it enough that, if the UA includes the "sr" flag, that the registrar > simply generates the Service-Route based on the Path and return it to > the UA? No. We need to know whether the proxies that inserted Path support this. Otherwise, they will get requests from a UA that include a Route header that they are not expecting. > > > My SECOND comment/question is on the "table" on page 9. In rows 2, 3 and > 5 it is indicated that the new SR procedures are used, ie the > Service-Route should override the outbound proxy in the UA. This is a bug in the spec. Sorry about that. In cases 2,3 and 5 the registrar would compute the service-route from the Path, HOWEVER it will not include the "sr" option tag in the response. This puts the UA in 'augment' mode, so that the service-route is added to the outbound proxy list in the UA. Now, in an > IMS scenario P1 could be a P-CSCF, and if it doesn't insert the "p2sr" > it would not receive the initial requests. Or, have I missunderstood? Per above, my error. In the IMS scenario where the visited network doesn't support this, the UA would keep its outbound proxy and use Route ontop of that. > > > My THIRD comment/question is on the statement in chapter 2.3. The text > says: > > "RFC 3261 is also clear that the resulting route set applies to > mid-dialog requests. It > implies (though does not explicitly say) that the resulting route set > overrides any default outbound proxies (which represent a pre-loaded > route set)." > > I don't think this is "clear" at all, and from my interop experience the > does-the-outbound-proxy-apply-to-mid-dialog-requests question comes up > quite often. And, just a couple of weeks ago I was informed about a > Cisco phone sending BYE to the outbound proxy, instead of using the > route set, so... ;) Well, I think its clear that the RR applies to mid-dialog requests. Whats not clear is outbound proxies. THis spec is tryign to make that crystal clear. > > > My FOURTH comment/question is on the statement in chapter 6.1, saying > that the Service-Route is recomputed for each registration. I think it > would be good to mention that in that sense the Service-Route is > DIFFERENT from Record-Route/Route, which is not recomputed (e.g. using > re-INVITE/UPDATE) once it has been created. Only the remote/local target > can be changed. OK. 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 Oct 31 13:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyKs-0000H4-Bp; Tue, 31 Oct 2006 13:27:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyKl-0000Gx-7r for sip@ietf.org; Tue, 31 Oct 2006 13:27:36 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyKd-0001fG-I6 for sip@ietf.org; Tue, 31 Oct 2006 13:27:35 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1303824ugd for ; Tue, 31 Oct 2006 10:27:23 -0800 (PST) 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=jzki7HbWznTEhgzLS2shm2DHc89QrgT0BKPxlZu7obn1xchzbBpDcoZf09z4lm/z2GK5IQeEFoDnTJuytOIr3ERmDt6ZIwHKbsDpsZ79aaYZmeb30qA5MFQT3Iv08Mx+VWiBzc3yj4Vs6Zfflk5ojbcsKRmyEAw6riGiYVbnEMs= Received: by 10.78.171.13 with SMTP id t13mr7215532hue; Tue, 31 Oct 2006 10:27:22 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 31 Oct 2006 10:27:22 -0800 (PST) Message-ID: <953beacc0610311027n3892d598q1c9ecf4c3f6ec01c@mail.gmail.com> Date: Tue, 31 Oct 2006 10:27:22 -0800 From: "Rohan Mahy" To: "Kevin Johns" Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-05 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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 10/30/06, Kevin Johns wrote: > What about the proposed changes to section 5.3? It is not listed in your > email so does that mean it was accepted without comment? (If so great as > I agreed with the change in wording as well.) yes. I like the proposed rewording. As I said: >> I like your proposed text. I'm pasting all these into the draft unless >> otherwise noted. thanks, -rohan > > 5.3 Forwarding Requests > > > > Otherwise, if the top- > > most Route header refers to the Edge Proxy and contains a valid > > flow > > identifier token created by this proxy, the proxy MUST remove the > > the > > Route header and forward the request over the flow that received > > the > > REGISTER request that caused the flow identifier token to be > > created. > > I suggest the following sentence instead : > > "Otherwise, if the top-most Route header refers to the Edge Proxy and > contains a valid flow identifier token created by this proxy, the proxy > MUST remove the Route header and forward the request over the flow > identified by the flow token". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeySm-0003oT-IH; Tue, 31 Oct 2006 13:35:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeySk-0003oI-0j; Tue, 31 Oct 2006 13:35:50 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeySe-00042O-3u; Tue, 31 Oct 2006 13:35:49 -0500 Received: from [172.17.1.79] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id k9VIZcma019585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Oct 2006 12:35:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <45479768.8020405@nostrum.com> Date: Tue, 31 Oct 2006 12:35:20 -0600 From: Adam Roach User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "'rohc@ietf.org'" References: <45477421.2080305@nostrum.com> In-Reply-To: <45477421.2080305@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: SIP WG , Keith Drage , Gonzalo Camarillo , Dean Willis Subject: [Sip] Re: Dedicated Review: draft-ietf-rohc-sigcomp-sip-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Adam Roach wrote: > In practice, the User Agent stores the Service-Route, and the > registrar (or some adjunct proxy to the registrar) stores the Path. > The only role the outbound proxy can play in this is by inserting > itself into the Service-Route and Path at registration time. I messed this up. The outbound proxy can't insert itself into the Service-Route; it can only insert itself into the Path. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 13:41:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyWF-0005Cu-QD; Tue, 31 Oct 2006 13:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyWD-0005At-R9 for sip@ietf.org; Tue, 31 Oct 2006 13:39:26 -0500 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyWC-0005LU-Ji for sip@ietf.org; Tue, 31 Oct 2006 13:39:25 -0500 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k9VIdCx00503; Tue, 31 Oct 2006 12:39:12 -0600 Date: Tue, 31 Oct 2006 12:39:12 -0600 Message-Id: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Francois Audet" , "Michael Thomas" , "Dean Willis" Subject: RE: [Sip] Re: What consensus? X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Joel M. Halpern" , IETF SIP List , Juha Heinanen , "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 > > LONG TERM: > > - We need to look at end-to-end security. I completely agree that it > probably > makes sense to start fresh on this (i.e., to NOT base it on SIPS). > > - I believe it is very likely that at some point, this will make sips > obsolete or > or at least quaint and primitive. That's OK too. > I think this is really the heart of this dicey issue. SIPS doesn't give end-to-end security but I would argue that end-to-end security may not be possible at all because of the basic architecture of SIP, i.e. signaling is routed through proxies. I wonder whether you need to force signaling to not traverse proxies somehow to really guarantee end-to-end security. If some proxy has the potential to see and modify the message, you just cannot give guarantees end-to-end. If this conjecture is true, then we may as well just do SIPS cuz its the best we can do. 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 Tue Oct 31 14:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyr4-0004PN-0Y; Tue, 31 Oct 2006 14:00:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geyr2-0004Hn-H0 for sip@ietf.org; Tue, 31 Oct 2006 14:00:56 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geyqy-0003Io-Is for sip@ietf.org; Tue, 31 Oct 2006 14:00:55 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 11:00:52 -0800 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 k9VJ0q9B010550; Tue, 31 Oct 2006 14:00:52 -0500 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 k9VJ0qDM010885; Tue, 31 Oct 2006 14:00:52 -0500 (EST) 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); Tue, 31 Oct 2006 14:00:51 -0500 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] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 14:00:51 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9GcRXfILpNtmJTTeKTZHj7bL/BQABNSLA From: "Sanjay Sinha \(sanjsinh\)" To: "Dean Willis" , "IETF SIP List" X-OriginalArrivalTime: 31 Oct 2006 19:00:51.0912 (UTC) FILETIME=[E2985C80:01C6FD1E] DKIM-Signature: a=rsa-sha1; q=dns; l=4080; t=1162321252; x=1163185252; c=relaxed/simple; s=rtpdkim1001; 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]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:=22Dean=20Willis=22=20, =20=22IETF=20SIP=20Lis t=22=20; X=v=3Dcisco.com=3B=20h=3DNF0oaGeXYLvOSL89WNDCSr2Vjxk=3D; b=pW2wA1cuC++twhFxF+8TH2zJiqLEPZYosVIsDGiE0t8EuDR6CJ00e/IjzywlU98NX56LJ7At KKnspADOKgRDVGLeVmAh3HHvQIBwHlvLjs+bK165GnXMi3bXGsj7/qBG; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Don't like the PSTN gateway limitation. As was mentioned in an earlier email, if signaling reaches PSTN gateway, it has reached UAS. Sanjay >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: Tuesday, October 31, 2006 1:21 PM >To: IETF SIP List >Subject: [Sip] A sips: trial balloon for you to shoot down > > >Ok, let me make a proposal, or perhaps remake one somebody=20 >else has made. I've lost track of who said what... > >I think we're now talking about a BCP for secure operations. > >1) Implementations of SIP SHOULD use TLS as described in RFC=20 >3261 for all SIP traffic, including traffic using a sip: URI=20 >scheme. Failure to use TLS may result in disclosure of=20 >sensitive signaling information to third parties. As a matter=20 >of local policy, some deployments MAY use IPSEC or physically=20 >protected infrastructure instead of TLS on specific links.=20 >Examples where this might be appropriate include persistent=20 >IPSEC relationships between proxies within an operational=20 >domain and physically protected "private network" cables=20 >between a TLS concentrator and the device it is fronting for.=20 >Where TLS is not used, the implementor MUST exercise a high=20 >level of caution to provide adequate security and MUST=20 >preserve operationally equivalent protection of message=20 >integrity, privacy, and participant identity (authentication). > >2) When using the sips: URI scheme, implementations MUST NOT=20 >exercise the "last hop exception" for sips: processing=20 >described in RFC 3261. =20 >Most scenarios where this technique might have seemed=20 >appropriate can be better satisfied using a client-initiated=20 >TLS connection as described in draft-ietf-sip-outbound. User=20 >agents that do not implement both TLS and either terminate TLS=20 >connections or exercise draft-ietf-sip-outbound with a=20 >US-originated TOS connection to an outbound will therefore not=20 >be able to exercise the sips: URI scheme. =20 >Failure to observe this requirement is likely to result in a=20 >reduction of operational security below that expected from the sips: =20 >URI scheme. > >3) Since some user-agents will not be able to exercise the sips: =20 >scheme, implementations MUST anticipate the failure of sips:=20 >requests and in general SHOULD use sips: only when it is=20 >desired that the request will not complete unless TLS will be=20 >used on each hop. Since requests using the sip: URI scheme are=20 >(by requirement 1 above) expected to be as securely processed=20 >as the implementation is able to do, it is not suggested that=20 >one first try sips: and then back off to sip:. In other words,=20 >if you're willing to settle for the best security that can=20 >actually be provided, simply originate the request with a sip:=20 >URI scheme. > >4) User agent servers that terminate a request using the sips:=20 >URI scheme MUST create any dependent requests using the sips:=20 >URI scheme. =20 >This preserves the commitments of the sips: scheme, and=20 >failure to observe this constraint would give the appearance=20 >of sips: security where no such security exists. For example,=20 >this requirement means that that back-to-back user agents=20 >bridging two sips: requests use >sips: on both sides. Furthermore, gateways to other protocols=20 >not offering equally strong protections MUST NOT exercise the=20 >sips: URI scheme. In particular, PSTN gateways MUST NOT use=20 >sips:, since the PSTN itself does not offer equivalent=20 >protections and there is no ability to determine whether the=20 >PSTN segment might be converted back to a sip: request=20 >somewhere downstream. > > >-- >Dean > > >_______________________________________________ >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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 14:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyyY-0002AF-DL; Tue, 31 Oct 2006 14:08:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeyyW-00026d-6i for sip@ietf.org; Tue, 31 Oct 2006 14:08:40 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeyyQ-00059n-Lh for sip@ietf.org; Tue, 31 Oct 2006 14:08:40 -0500 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 k9VJ1dj17900; Tue, 31 Oct 2006 14:01:39 -0500 (EST) 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] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 13:08:09 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DC998FE@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9GbslcXSwEdJaTM+p5uqW1LLVAgAASZ6w From: "Francois Audet" To: "Dean Willis" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 31, 2006 10:21 AM > To: IETF SIP List > Subject: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > Ok, let me make a proposal, or perhaps remake one somebody=20 > else has made. I've lost track of who said what... >=20 > I think we're now talking about a BCP for secure operations. >=20 > 1) Implementations of SIP SHOULD use TLS as described in RFC=20 > 3261 for all SIP traffic, including traffic using a sip: URI=20 > scheme. Failure to use TLS may result in disclosure of=20 > sensitive signaling information to third parties. As a matter=20 > of local policy, some deployments MAY use IPSEC or physically=20 > protected infrastructure instead of TLS on specific links.=20 > Examples where this might be appropriate include persistent=20 > IPSEC relationships between proxies within an operational=20 > domain and physically protected "private network" cables=20 > between a TLS concentrator and the device it is fronting for.=20 > Where TLS is not used, the implementor MUST exercise a high=20 > level of caution to provide adequate security and MUST=20 > preserve operationally equivalent protection of message=20 > integrity, privacy, and participant identity (authentication). That first recommendation seems to be completely independent from SIPS, right? Seems reasonable to me. That sounds like BCP-material for sure. Something for a new document. > 2) When using the sips: URI scheme, implementations MUST NOT=20 > exercise the "last hop exception" for sips: processing=20 > described in RFC 3261. =20 > Most scenarios where this technique might have seemed=20 > appropriate can be better satisfied using a client-initiated=20 > TLS connection as described in draft-ietf-sip-outbound. User=20 > agents that do not implement both TLS and either terminate=20 > TLS connections or exercise draft-ietf-sip-outbound with a=20 > US-originated TOS connection to an outbound will therefore=20 > not be able to exercise the sips: URI scheme. =20 > Failure to observe this requirement is likely to result in a=20 > reduction of operational security below that expected from the sips: =20 > URI scheme. I like the idea of deprecating the last-hop exception. My makes the exact same case your are making here (but it falls short of deprecating the last-hop exception, because, the chair has instructed me to not make normative changes). I'm assuming that=20 making a normative change to RFC 3261 for this would require a=20 new document. What is not clear from this is if there are any relationship with your proposal (1). Specifically, I believe that most people believe=20 that sips does imply TLS (and does not allow for IPsec). Are you=20 proposing to change this so that (1) applies to sips as well?=20 > 3) Since some user-agents will not be able to exercise the sips: =20 > scheme, implementations MUST anticipate the failure of sips:=20 > requests and in general SHOULD use sips: only when it is=20 > desired that the request will not complete unless TLS will be=20 > used on each hop. Since requests using the sip: URI scheme=20 > are (by requirement 1 above) expected to be as securely=20 > processed as the implementation is able to do, it is not=20 > suggested that one first try sips: and then back off to sip:.=20 > In other words, if you're willing to settle for the best=20 > security that can actually be provided, simply originate the=20 > request with a sip: URI scheme. That is already covered in my draft (and in RFC 3261).=20 No need to do anything else about it. > 4) User agent servers that terminate a request using the=20 > sips: URI scheme MUST create any dependent requests using the=20 > sips: URI scheme. =20 > This preserves the commitments of the sips: scheme, and=20 > failure to observe this constraint would give the appearance=20 > of sips: security where no such security exists. For example,=20 > this requirement means that that back-to-back user agents=20 > bridging two sips: requests use > sips: on both sides. Furthermore, gateways to other protocols=20 > not offering equally strong protections MUST NOT exercise the=20 > sips: URI scheme. In particular, PSTN gateways MUST NOT use=20 > sips:, since the PSTN itself does not offer equivalent=20 > protections and there is no ability to determine whether the=20 > PSTN segment might be converted back to a sip: request=20 > somewhere downstream. I think this is likely to be somewhat controversial (the pstn=20 gateway limitation in particular). I can go either way. I guess this is also BCP material. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 14:15:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez2u-0006BN-6d; Tue, 31 Oct 2006 14:13:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez2s-0006Af-A5 for sip@ietf.org; Tue, 31 Oct 2006 14:13:10 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gez2l-00069O-Rp for sip@ietf.org; Tue, 31 Oct 2006 14:13:10 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4DDD375E; Tue, 31 Oct 2006 20:13:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 20:13:03 +0100 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] One big concern with outbound-05 Date: Tue, 31 Oct 2006 20:12:06 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045A33A6@esealmw113.eemea.ericsson.se> In-Reply-To: <953beacc0610311022j2fb4ef0eh6eb5c3ec6598d9a6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] One big concern with outbound-05 Thread-Index: Acb9GZHhfC/FixH2QU+hSE7lAfQ/GQABlLVg From: "Christer Holmberg \(JO/LMF\)" To: "Rohan Mahy" X-OriginalArrivalTime: 31 Oct 2006 19:13:03.0274 (UTC) FILETIME=[968558A0:01C6FD20] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, 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 Hi Rohan,=20 >>>I do however see the problem you are talking about with Outbound=20 >>>effectively being disabled if there is some other proxy on the way=20 >>>between the UA and the registrar that adds itself to the Path vector=20 >>>for some non-Outbound reason, and not including the ;ob parameter=20 >>>since it doesn't know about Outbound. In that case,=20 >>>reachability from the Authoritative proxy / registrar to the UA won't be guaranteed. >>> >>>Changing it to what you suggest, only demand the edge proxy closest=20 >>>to the UA to support Outbound, would of course (at least slightly)=20 >>>reduce the chance of reachability from the Authoritative proxy /=20 >>>registrar to the UA, but at least until now I haven't been able to=20 >>>come to any other conclusion than that it would probably work often=20 >>>enough (because the edge proxys closest to the UA probably will have=20 >>>global reachability)... >>>I am looking forward to Rohan's response to this. >> >>Me too :) >=20 >Perhaps I am going too far in trying to insure connectivity=20 >back to the UA. Today there are some networks that don't=20 >require a border signaling element and some that do. The=20 >assumption that the border element for foo.com can reach any=20 >edge proxy for foo.com pre-dates outbound, but it is kind of brittle. >=20 >The current outbound draft provides a more reliable assurance=20 >of working connectivity, but at the price of requiring more=20 >devices in the path to understand outbound. I strongly don't think we should have that requirement. It should be possible to use outbound if only the edge proxy and registrar support outbound. We can of course add some text talking about the advantages of all proxies supporting outbound, but I don't think we should mandate it. 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 Tue Oct 31 14:15:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez3H-0006XE-Vb; Tue, 31 Oct 2006 14:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gez39-0006SE-7L for sip@ietf.org; Tue, 31 Oct 2006 14:13:29 -0500 Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gez31-0006DJ-IL for sip@ietf.org; Tue, 31 Oct 2006 14:13:27 -0500 Received: from eng.infointeractive.com ([10.142.0.50]:63083 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S407136AbWJaTMh (ORCPT ); Tue, 31 Oct 2006 15:12:37 -0400 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <5846-514>; Tue, 31 Oct 2006 15:12:35 -0400 Date: Tue, 31 Oct 2006 15:12:35 -0400 From: David Benoit To: fwmiller@cornfed.com Subject: Re: [Sip] Re: What consensus? Message-ID: <20061031191235.GA10111@infointeractive.com> References: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Michael Thomas , "Joel M. Halpern" , Francois Audet , IETF SIP List , Juha Heinanen , "Elwell, John" , 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 Tue, Oct 31, 2006 at 12:39:12PM -0600, fwmiller@cornfed.com wrote: > I think this is really the heart of this dicey issue. SIPS doesn't > give end-to-end security but I would argue that end-to-end security > may not be possible at all because of the basic architecture of SIP, > i.e. signaling is routed through proxies. I wonder whether you need > to force signaling to not traverse proxies somehow to really guarantee > end-to-end security. If some proxy has the potential to see and > modify the message, you just cannot give guarantees end-to-end. > > If this conjecture is true, then we may as well just do SIPS cuz its > the best we can do. I've been reading this thread for a while now, and I think I should chime in. In any example of a commercial service using SIP, and almost all other services I can think of, there are "things in the middle". The world of true "peer-to-peer" communications using SIP just doesn't exist (especially in light of the problems addressed in the outbound draft). Providers place proxies/B2BUAs/etc. in the middle to do a number of things for: 1) control: knowing that an endpoint has to communicate through a specific gateway/proxy/whatever you want to call it provides a large amount of value 2) monetization: service providers like to charge for access, so we put proxies in the middle to control access to those services. 3) privacy: how else could you effectively enforce privacy of information other than having a proxy/gateway strip out the affected information; you certainly can't trust the UAC to do it. 4) protection: having only one (redundant) entry point into your network allows you to build a walled garden and build different levels of protection from DoS attacks, etc. 5) simplicity: routing messages becomes MUCH easier in this type of setup. 6) monitoring: SPs like to monitor the "health" of a service. Doing so without clearly defined interface and anchoring points is much harder. 7) peering: when one SP talks to another SP, they usually do so over controlled endpoints that are most certainly going to be B2BUAs. etc. I think it is VERY unlikely that any SP is going to give up all of these things, so they will continue to use stateful proxies and B2BUAs. This means that your conjecture is true. SPs are not going to want to "force signaling to not traverse proxies" because that will directly impact those points above. In the world of SIP, I don't think you can actually achieve end-to-end encryption of the signaling. I really think when you consider the problem as a whole, you will realize that the only thing you could possibly guarantee is that the signaling will be "private" from the UAC to the first proxy (the one that implements all the recommendations in sip-outbound). Even then, if you don't provide any kind of encryption on the media, what's the point? Add to that the world of PSTN internetworking, CALEA, etc., and you can't really guarantee that anything is really "private". David ASIDE: is it really even useful to dictate that "SIPS" can't be over DTLS instead of TLS? That is only a limitation of the technology available at the time of writing 3261, is it not? Why not have the "transport" parameter indicate which to use, just like we do with "SIP"? -- David.Benoit@InfoInteractive.com | phone: 902-832-2649 fax: 902-832-1015 "Complex problems have simple, neat and wrong solutions" - H. L. Menken _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 14:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezHW-00076W-Vm; Tue, 31 Oct 2006 14:28:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GezHU-000760-J1 for sip@ietf.org; Tue, 31 Oct 2006 14:28:16 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GezHP-0001RW-9D for sip@ietf.org; Tue, 31 Oct 2006 14:28:16 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8BAF9F36; Tue, 31 Oct 2006 20:28:08 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 20:28:08 +0100 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 route construct specification Date: Tue, 31 Oct 2006 20:23:05 +0100 Message-ID: <5EB80D22825EEE42872083AD5BFFB594045A33BD@esealmw113.eemea.ericsson.se> In-Reply-To: <454795A5.10000@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Updated route construct specification Thread-Index: Acb9GkdKVOW9G7ndTRa5G0r1zQByHAABkWAA From: "Christer Holmberg \(JO/LMF\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 31 Oct 2006 19:28:08.0565 (UTC) FILETIME=[B21DCA50:01C6FD22] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) 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 Hi Jonathan,=20 >>My FIRST comment/question is: do we really need the "p2sr"=20 >>flag? Isn't it enough that, if the UA includes the "sr" flag, that the >>registrar simply generates the Service-Route based on the Path and=20 >>return it to the UA? >=20 >No. We need to know whether the proxies that inserted Path=20 >support this. Otherwise, they will get requests from a UA that include a=20 >Route header that they are not expecting. That can happen already today, because those proxies cannot prevent the registrar from inserting a Service-Route pointing towards them (which I belive is fully allowed). Regards, Christer =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 Oct 31 15:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0GS-0004U7-F9; Tue, 31 Oct 2006 15:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0GM-0004U1-9s for sip@ietf.org; Tue, 31 Oct 2006 15:31:10 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0GH-0005V8-NV for sip@ietf.org; Tue, 31 Oct 2006 15:31:10 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJYaYn013631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:34:36 -0600 In-Reply-To: <03b501c6fd18$de489920$c5f0200a@amer.cisco.com> References: <03b501c6fd18$de489920$c5f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <801AC858-0B14-4A85-A298-E3E7C1EF70A4@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 14:30:58 -0600 To: Dan Wing X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "'Joel M. Halpern'" , '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 Oct 31, 2006, at 12:17 PM, Dan Wing wrote: > > They're close. What I'd like is the ability to get TLS > everywhere I can, and still allow a call to complete > in the event a hop or two couldn't get TLS. With > Require, I believe a proxy will not forward the INVITE > if it can't provide TLS on that next hop, right? > Right. So now you're more into the realm of Caller-Preferences. But if we made SIP guidance "Use TLS (or rough equivalent) if you can, and only use a plain connection if you have alternative" for all calls, wouldn't that default to what you're asking for? -- 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 Oct 31 15:35:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0IP-0004bp-KH; Tue, 31 Oct 2006 15:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0IN-0004ZH-5f for sip@ietf.org; Tue, 31 Oct 2006 15:33:15 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0ID-0005eM-Ft for sip@ietf.org; Tue, 31 Oct 2006 15:33:15 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJaYpJ013639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:36:36 -0600 In-Reply-To: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> References: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: What consensus? Date: Tue, 31 Oct 2006 14:32:56 -0600 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Michael Thomas , "Joel M. Halpern" , Francois Audet , IETF SIP List , Juha Heinanen , "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 On Oct 31, 2006, at 12:39 PM, fwmiller@cornfed.com wrote: > >> >> LONG TERM: >> >> - We need to look at end-to-end security. I completely agree that it >> probably >> makes sense to start fresh on this (i.e., to NOT base it on SIPS). >> >> - I believe it is very likely that at some point, this will make sips >> obsolete or >> or at least quaint and primitive. That's OK too. >> > > I think this is really the heart of this dicey issue. SIPS doesn't > give end-to-end security but I would argue that end-to-end security > may not be possible at all because of the basic architecture of > SIP, i.e. signaling is routed through proxies. I wonder whether > you need to force signaling to not traverse proxies somehow to > really guarantee end-to-end security. If some proxy has the > potential to see and modify the message, you just cannot give > guarantees end-to-end. Nah, HTTPS goes through proxies without compromising the security. So we have a proof it can be done. See the sipsec draft from Vijay for more discussion. -- 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 Oct 31 15:36:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Je-0005Dd-Da; Tue, 31 Oct 2006 15:34:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Jb-00057n-9D for sip@ietf.org; Tue, 31 Oct 2006 15:34:31 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0JQ-0005n0-6i for sip@ietf.org; Tue, 31 Oct 2006 15:34:31 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJbr2Z013650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:37:54 -0600 In-Reply-To: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> References: <8983EC086A9D954BA74D9763E853CF3E024780CA@xmb-rtp-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41760DE2-915E-4CE7-95B3-0031202E10CE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 14:34:15 -0600 To: Sanjay Sinha ((sanjsinh)) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Oct 31, 2006, at 1:00 PM, Sanjay Sinha ((sanjsinh)) wrote: > Don't like the PSTN gateway limitation. As was mentioned in an earlier > email, if signaling reaches PSTN gateway, it has reached UAS. But what's the diff between (PSTN gateway, a hunk of PSTN, another PSTN gateway) and an SBC? Both provide the same downgrade attack if we don't have this requirement. -- 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 Oct 31 15:41:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Ou-0002y9-U3; Tue, 31 Oct 2006 15:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Os-0002y0-D2 for sip@ietf.org; Tue, 31 Oct 2006 15:39:58 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0Of-0006QE-Tt for sip@ietf.org; Tue, 31 Oct 2006 15:39:58 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJhJr5013688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:43:20 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC998FE@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DC998FE@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C1D8CE0-DE2A-4430-A4B6-8DB6CB93787C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 14:39:42 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Oct 31, 2006, at 1:08 PM, Francois Audet wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Tuesday, October 31, 2006 10:21 AM >> To: IETF SIP List >> Subject: [Sip] A sips: trial balloon for you to shoot down >> >> >> Ok, let me make a proposal, or perhaps remake one somebody >> else has made. I've lost track of who said what... >> >> I think we're now talking about a BCP for secure operations. >> >> 1) Implementations of SIP SHOULD use TLS as described in RFC >> 3261 for all SIP traffic, including traffic using a sip: URI >> scheme. Failure to use TLS may result in disclosure of >> sensitive signaling information to third parties. As a matter >> of local policy, some deployments MAY use IPSEC or physically >> protected infrastructure instead of TLS on specific links. >> Examples where this might be appropriate include persistent >> IPSEC relationships between proxies within an operational >> domain and physically protected "private network" cables >> between a TLS concentrator and the device it is fronting for. >> Where TLS is not used, the implementor MUST exercise a high >> level of caution to provide adequate security and MUST >> preserve operationally equivalent protection of message >> integrity, privacy, and participant identity (authentication). > > That first recommendation seems to be completely independent from > SIPS, right? Seems reasonable to me. That sounds like BCP-material > for sure. Something for a new document. > >> 2) When using the sips: URI scheme, implementations MUST NOT >> exercise the "last hop exception" for sips: processing >> described in RFC 3261. >> Most scenarios where this technique might have seemed >> appropriate can be better satisfied using a client-initiated >> TLS connection as described in draft-ietf-sip-outbound. User >> agents that do not implement both TLS and either terminate >> TLS connections or exercise draft-ietf-sip-outbound with a >> US-originated TOS connection to an outbound will therefore >> not be able to exercise the sips: URI scheme. >> Failure to observe this requirement is likely to result in a >> reduction of operational security below that expected from the sips: >> URI scheme. > > I like the idea of deprecating the last-hop exception. My makes the > exact same case your are making here (but it falls > short of deprecating the last-hop exception, because, the chair has > instructed me to not make normative changes). I'm assuming that > making a normative change to RFC 3261 for this would require a > new document. I'd argue that making a normative statement about how to best USE 3261 is not the same as making a normative change to 3261. Thus, this sort of behavioral requirement can be made in a BCP, without it actually changing 3261 or being a standards-track document. > > What is not clear from this is if there are any relationship with > your proposal (1). Specifically, I believe that most people believe > that sips does imply TLS (and does not allow for IPsec). Are you > proposing to change this so that (1) applies to sips as well? Nope. 1 is all about sip:. It is there to make sure that you get the best possible security if you don't use sips:, thereby allowing you to use sips: only when you want to make the call to fail if TLS is not present on EVERY hop. > >> 3) Since some user-agents will not be able to exercise the sips: >> scheme, implementations MUST anticipate the failure of sips: >> requests and in general SHOULD use sips: only when it is >> desired that the request will not complete unless TLS will be >> used on each hop. Since requests using the sip: URI scheme >> are (by requirement 1 above) expected to be as securely >> processed as the implementation is able to do, it is not >> suggested that one first try sips: and then back off to sip:. >> In other words, if you're willing to settle for the best >> security that can actually be provided, simply originate the >> request with a sip: URI scheme. > > That is already covered in my draft (and in RFC 3261). > No need to do anything else about it. > No, this really say "Don't use sips: as your default mechanism. Only use it when you REALLY REALLY want the call to fail if EVERY link, including the last hop, is not TLS." Again, it;s not a change the the specification of 3261 -- it's a guideline on how to best use it. Behaviour needs reinforcing from time to time. >> 4) User agent servers that terminate a request using the >> sips: URI scheme MUST create any dependent requests using the >> sips: URI scheme. >> This preserves the commitments of the sips: scheme, and >> failure to observe this constraint would give the appearance >> of sips: security where no such security exists. For example, >> this requirement means that that back-to-back user agents >> bridging two sips: requests use >> sips: on both sides. Furthermore, gateways to other protocols >> not offering equally strong protections MUST NOT exercise the >> sips: URI scheme. In particular, PSTN gateways MUST NOT use >> sips:, since the PSTN itself does not offer equivalent >> protections and there is no ability to determine whether the >> PSTN segment might be converted back to a sip: request >> somewhere downstream. > > I think this is likely to be somewhat controversial (the pstn > gateway limitation in particular). > See discussion elsewhere -- without this requirement, sips: is exactly the same wishful thinking that sip: is (ok, do your best . . .) and might as well be deprecated. -- 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 Oct 31 15:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Rj-000425-5k; Tue, 31 Oct 2006 15:42:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0Rh-00041Z-2p for sip@ietf.org; Tue, 31 Oct 2006 15:42:53 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0Rf-0006kt-58 for sip@ietf.org; Tue, 31 Oct 2006 15:42:52 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJkJb3013710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:46:20 -0600 In-Reply-To: <20061031191235.GA10111@infointeractive.com> References: <200610311839.k9VIdCx00503@smapp01.siteprotect.com> <20061031191235.GA10111@infointeractive.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: What consensus? Date: Tue, 31 Oct 2006 14:42:41 -0600 To: David Benoit X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Michael Thomas , "Joel M. Halpern" , Francois Audet , IETF SIP List , Juha Heinanen , fwmiller@cornfed.com, "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 On Oct 31, 2006, at 1:12 PM, David Benoit wrote: > > 1) control: knowing that an endpoint has to communicate through a > specific gateway/proxy/whatever you want to call it provides a > large amount of value > 2) monetization: service providers like to charge for access, so we > put proxies in the middle to control access to those services. > 3) privacy: how else could you effectively enforce privacy of > information other than having a proxy/gateway strip out the > affected information; you certainly can't trust the UAC to do it. > 4) protection: having only one (redundant) entry point into your > network allows you to build a walled garden and build different > levels of protection from DoS attacks, etc. > 5) simplicity: routing messages becomes MUCH easier in this type of > setup. > 6) monitoring: SPs like to monitor the "health" of a service. Doing > so without clearly defined interface and anchoring points is much > harder. > 7) peering: when one SP talks to another SP, they usually do so over > controlled endpoints that are most certainly going to be B2BUAs. I'd like to point out that all of the above (outside of things that require "looking at the sdp", which includes some privacy functions) can be implemented using the sipsec: approach, without any of the inherent weaknesses of the sip: approach. Privacy functions can be done by having the privacy-requesting UA make pre-arranagements with an anonymizer, then use info from the anonymizer to fill out its SDP -- more work, but without the security weakness. -- 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 Oct 31 15:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0eh-0004df-SQ; Tue, 31 Oct 2006 15:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0ef-0004YL-Ee for sip@ietf.org; Tue, 31 Oct 2006 15:56:17 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0ed-00084l-3k for sip@ietf.org; Tue, 31 Oct 2006 15:56:17 -0500 Received: from [192.168.2.102] ([12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k9VJxm7h013815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Oct 2006 13:59:48 -0600 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC996EF@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0DC996EF@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: What consensus? Date: Tue, 31 Oct 2006 14:56:10 -0600 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Joel M. Halpern" , IETF SIP List , Juha Heinanen , Michael Thomas , "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 On Oct 31, 2006, at 11:48 AM, Francois Audet wrote: > > This is I believe why we are having such a hard time with sips. > . . . > > The only thing that sips does is allow for extending the SIPoverTLS > hop-by-hop (without sips) like this: > > - Allows for dynamically requesting that a request be sent over TLS > on all hops (except the last one unfortunately) and FAIL that > request > if not possible. (i.e., it is the equivalent to a Proxy-Require: > SIP/TLS > if that existed). > > That's it. > But for sips: to live up to the promise you just made, it needs more restrictions specifically relating to gateway and B2BUA operations. This puts us in a weird place. Some of us don't want sips: to mean what it says. Others of us don't want it to say what it means. Either it means "MUST use some specific level of protection (easily said as TLS)", or it just means "Protection would be nice if you can do it", which we already get from the sip: URI scheme. -- 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 Oct 31 16:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0t5-00054F-8G; Tue, 31 Oct 2006 16:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0sy-000545-R0 for sip@ietf.org; Tue, 31 Oct 2006 16:11:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0sx-0000rK-IK for sip@ietf.org; Tue, 31 Oct 2006 16:11:04 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 13:11:03 -0800 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 k9VLB3OQ006622; Tue, 31 Oct 2006 13:11:03 -0800 Received: from dwingwxp (dhcp-171-69-133-63.cisco.com [171.69.133.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VLAwOV028841; Tue, 31 Oct 2006 13:10:58 -0800 (PST) From: "Dan Wing" To: "'Dean Willis'" Subject: RE: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) Date: Tue, 31 Oct 2006 13:10:58 -0800 Keywords: direct-to-dwing Message-ID: <073401c6fd31$125a9930$c5f0200a@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: Acb9K4JpEpZh8T7cQyOqHbbcz0/rpgABVBJQ In-Reply-To: <801AC858-0B14-4A85-A298-E3E7C1EF70A4@softarmor.com> DKIM-Signature: a=rsa-sha1; q=dns; l=624; t=1162329063; x=1163193063; 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=20What=20controls=20the=20lock=20icon?=20(Was=20RE=3A=20[Sip]=20RE =3A=20TLS=20=20meaning); X=v=3Dcisco.com=3B=20h=3D59UMOjsl4qSM1GeKz5v65xpvfWE=3D; b=IqO2G76D1tMZHvvsuEItwwXOc5/JSKHi+ZEk7vYORXV6lr2usUswSV3Q7IVajDAPicJggaj2 putfVboUQf8TNbOGq5wDoI8qA6rFi6jNHsaU3vjYRDopZjfDnvlZHFcc; 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: cf4fa59384e76e63313391b70cd0dd25 Cc: "'Joel M. Halpern'" , '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 > > They're close. What I'd like is the ability to get TLS > > everywhere I can, and still allow a call to complete > > in the event a hop or two couldn't get TLS. With > > Require, I believe a proxy will not forward the INVITE > > if it can't provide TLS on that next hop, right? > > > > Right. So now you're more into the realm of Caller-Preferences. > > But if we made SIP guidance "Use TLS (or rough equivalent) if you > can, and only use a plain connection if you have alternative" > for all calls, wouldn't that default to what you're asking for? Yes. That should be standard operating procedure. -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 Oct 31 16:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0ud-0005RE-U4; Tue, 31 Oct 2006 16:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0uW-0005OV-2B for sip@ietf.org; Tue, 31 Oct 2006 16:12:41 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0uU-0000y9-L6 for sip@ietf.org; Tue, 31 Oct 2006 16:12:40 -0500 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 k9VLCZ704564; Tue, 31 Oct 2006 16:12:35 -0500 (EST) 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] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 15:12:19 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF0DCE786D@zrc2hxm0.corp.nortel.com> In-Reply-To: <6C1D8CE0-DE2A-4430-A4B6-8DB6CB93787C@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9LL36RLfxUvULTSqhQXWfR7hYfAAA1/vQ From: "Francois Audet" To: "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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'm happy with your proposal, as per your clarification. I guess it would mean a new BCP document (plus some changes to my draft for some sips-related aspects). > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, October 31, 2006 12:40 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: Re: [Sip] A sips: trial balloon for you to shoot down >=20 >=20 > On Oct 31, 2006, at 1:08 PM, Francois Audet wrote: >=20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: Tuesday, October 31, 2006 10:21 AM > >> To: IETF SIP List > >> Subject: [Sip] A sips: trial balloon for you to shoot down > >> > >> > >> Ok, let me make a proposal, or perhaps remake one somebody=20 > else has=20 > >> made. I've lost track of who said what... > >> > >> I think we're now talking about a BCP for secure operations. > >> > >> 1) Implementations of SIP SHOULD use TLS as described in RFC > >> 3261 for all SIP traffic, including traffic using a sip:=20 > URI scheme.=20 > >> Failure to use TLS may result in disclosure of sensitive signaling=20 > >> information to third parties. As a matter of local policy, some=20 > >> deployments MAY use IPSEC or physically protected infrastructure=20 > >> instead of TLS on specific links. > >> Examples where this might be appropriate include persistent IPSEC=20 > >> relationships between proxies within an operational domain and=20 > >> physically protected "private network" cables between a TLS=20 > >> concentrator and the device it is fronting for. > >> Where TLS is not used, the implementor MUST exercise a=20 > high level of=20 > >> caution to provide adequate security and MUST preserve=20 > operationally=20 > >> equivalent protection of message integrity, privacy, and=20 > participant=20 > >> identity (authentication). > > > > That first recommendation seems to be completely independent from=20 > > SIPS, right? Seems reasonable to me. That sounds like=20 > BCP-material for=20 > > sure. Something for a new document. > > > >> 2) When using the sips: URI scheme, implementations MUST=20 > NOT exercise=20 > >> the "last hop exception" for sips: processing described in=20 > RFC 3261. > >> Most scenarios where this technique might have seemed=20 > appropriate can=20 > >> be better satisfied using a client-initiated TLS connection as=20 > >> described in draft-ietf-sip-outbound. User agents that do not=20 > >> implement both TLS and either terminate TLS connections or=20 > exercise=20 > >> draft-ietf-sip-outbound with a US-originated TOS connection to an=20 > >> outbound will therefore not be able to exercise the sips:=20 > URI scheme. > >> Failure to observe this requirement is likely to result in a=20 > >> reduction of operational security below that expected from=20 > the sips: > >> URI scheme. > > > > I like the idea of deprecating the last-hop exception. My makes the=20 > > exact same case your are making here (but it falls short of=20 > > deprecating the last-hop exception, because, the chair has=20 > instructed=20 > > me to not make normative changes). I'm assuming that making a=20 > > normative change to RFC 3261 for this would require a new document. >=20 > I'd argue that making a normative statement about how to best USE > 3261 is not the same as making a normative change to 3261.=20 > Thus, this sort of behavioral requirement can be made in a=20 > BCP, without it actually changing 3261 or being a=20 > standards-track document. >=20 > > > > What is not clear from this is if there are any=20 > relationship with your=20 > > proposal (1). Specifically, I believe that most people=20 > believe that=20 > > sips does imply TLS (and does not allow for IPsec). Are you=20 > proposing=20 > > to change this so that (1) applies to sips as well? >=20 > Nope. 1 is all about sip:. It is there to make sure that you=20 > get the best possible security if you don't use sips:,=20 > thereby allowing you to use sips: only when you want to make=20 > the call to fail if TLS is not present on EVERY hop. > > > >> 3) Since some user-agents will not be able to exercise the sips: > >> scheme, implementations MUST anticipate the failure of sips: > >> requests and in general SHOULD use sips: only when it is=20 > desired that=20 > >> the request will not complete unless TLS will be used on each hop.=20 > >> Since requests using the sip: URI scheme are (by=20 > requirement 1 above)=20 > >> expected to be as securely processed as the implementation=20 > is able to=20 > >> do, it is not suggested that one first try sips: and then=20 > back off to=20 > >> sip:. > >> In other words, if you're willing to settle for the best security=20 > >> that can actually be provided, simply originate the request with a=20 > >> sip: URI scheme. > > > > That is already covered in my draft (and in RFC 3261). > > No need to do anything else about it. > > >=20 > No, this really say "Don't use sips: as your default=20 > mechanism. Only use it when you REALLY REALLY want the call=20 > to fail if EVERY link, including the last hop, is not TLS."=20 > Again, it;s not a change the the specification of 3261 --=20 > it's a guideline on how to best use it. =20 > Behaviour needs reinforcing from time to time. >=20 >=20 > >> 4) User agent servers that terminate a request using the > >> sips: URI scheme MUST create any dependent requests using the > >> sips: URI scheme. > >> This preserves the commitments of the sips: scheme, and failure to=20 > >> observe this constraint would give the appearance of sips:=20 > security=20 > >> where no such security exists. For example, this requirement means=20 > >> that that back-to-back user agents bridging two sips: requests use > >> sips: on both sides. Furthermore, gateways to other protocols not=20 > >> offering equally strong protections MUST NOT exercise the > >> sips: URI scheme. In particular, PSTN gateways MUST NOT use sips:,=20 > >> since the PSTN itself does not offer equivalent=20 > protections and there=20 > >> is no ability to determine whether the PSTN segment might be=20 > >> converted back to a sip: request somewhere downstream. > > > > I think this is likely to be somewhat controversial (the=20 > pstn gateway=20 > > limitation in particular). > > >=20 > See discussion elsewhere -- without this requirement, sips:=20 > is exactly the same wishful thinking that sip: is (ok, do=20 > your best . . .) and might as well be deprecated. >=20 > -- > Dean >=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 Oct 31 16:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0uf-0005WI-Cp; Tue, 31 Oct 2006 16:12:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf0uZ-0005Qj-4r for sip@ietf.org; Tue, 31 Oct 2006 16:12:43 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf0uX-0000yS-Sy for sip@ietf.org; Tue, 31 Oct 2006 16:12:43 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 13:12:41 -0800 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 k9VLCfWt031290; Tue, 31 Oct 2006 16:12:41 -0500 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 k9VLCdYJ009625; Tue, 31 Oct 2006 16:12:39 -0500 (EST) 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); Tue, 31 Oct 2006 16:12:39 -0500 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] A sips: trial balloon for you to shoot down Date: Tue, 31 Oct 2006 16:12:38 -0500 Message-ID: <8983EC086A9D954BA74D9763E853CF3E024D29E2@xmb-rtp-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] A sips: trial balloon for you to shoot down Thread-Index: Acb9LAaWzt1LC62CRX+09ZKy6KqIVgAAc3zQ From: "Sanjay Sinha \(sanjsinh\)" To: "Dean Willis" X-OriginalArrivalTime: 31 Oct 2006 21:12:39.0225 (UTC) FILETIME=[4BB89290:01C6FD31] DKIM-Signature: a=rsa-sha1; q=dns; l=1070; t=1162329161; x=1163193161; c=relaxed/simple; s=rtpdkim1001; 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]=20A=20sips=3A=20trial=20balloon=20for=20you=20to=20shoot=2 0down |To:=22Dean=20Willis=22=20; X=v=3Dcisco.com=3B=20h=3DNF0oaGeXYLvOSL89WNDCSr2Vjxk=3D; b=dGuHdBgaRQLS5aH3cdnTWjDo9DGCZQxuhJ07OlPZonvC/uE0R1Ind8nrEq+gcNjdJwJrf8i4 SgEDHMLhfpra0cOC3XW4xJaGjpdAdu8FV+THJABYhvjetiXvH+tthTcL; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 =20 >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: Tuesday, October 31, 2006 3:34 PM >To: Sanjay Sinha (sanjsinh) >Cc: IETF SIP List >Subject: Re: [Sip] A sips: trial balloon for you to shoot down > > >On Oct 31, 2006, at 1:00 PM, Sanjay Sinha ((sanjsinh)) wrote: > >> Don't like the PSTN gateway limitation. As was mentioned in=20 >an earlier=20 >> email, if signaling reaches PSTN gateway, it has reached UAS. > >But what's the diff between (PSTN gateway, a hunk of PSTN,=20 >another PSTN gateway) and an SBC? Both provide the same=20 >downgrade attack if we don't have this requirement. It is my understanding is that SBC is esentially a B2BUA or an IP-IP gateway, if one leg is SIP and another one is say, H323/MGCP. A pstn gateway is termination point of IP leg signaling. It will have fxs/pots or a PBX interface on the other leg. So I can have an IAD with pots phones hanging off of fxs port in a small branch office and know that interface is secure/trusted. Sanjay > >-- >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 Oct 31 16:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1Zb-0000Lq-7n; Tue, 31 Oct 2006 16:55:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1ZY-0000Gl-J2 for sip@ietf.org; Tue, 31 Oct 2006 16:55:04 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1ZX-0005UG-9b for sip@ietf.org; Tue, 31 Oct 2006 16:55:04 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gf1ZW-0005ff-Ge for sip@ietf.org; Tue, 31 Oct 2006 16:55:02 -0500 Message-Id: <7.0.1.0.0.20061031165049.0354acf0@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 31 Oct 2006 16:54:10 -0500 To: "'IETF SIP List'" From: "Joel M. Halpern" Subject: Re: What controls the lock icon? (Was RE: [Sip] RE: TLS meaning) In-Reply-To: <89CE38BD-EB0C-47B9-8429-E5A31AEF0090@softarmor.com> References: <7.0.1.0.0.20061030133854.03581610@stevecrocker.com> <031f01c6fc59$5fedd9b0$640fa8c0@cis.neustar.com> <7.0.1.0.0.20061030164413.035913f8@stevecrocker.com> <09C8234F-2946-4C48-854C-5CF5F4EEEF0E@softarmor.com> <7.0.1.0.0.20061031071800.034d6f50@stevecrocker.com> <89CE38BD-EB0C-47B9-8429-E5A31AEF0090@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120858b83b80a5943d155c578cab5bb75dca6100a05dea77183350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) 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 But, as the security folks have said many times, in many places "trust is not transitive." The fact that I trust my first proxy to do the right thing does not mean that I trust all the proxies it trusts. And it most certainly does not mean that I trust all the proxies that those proxies trust. So saying that SIPS allows me to demand something and expect to get it not only requires a high level of local trust (a not unreasonable thing in many contexts) but a high level of transitive trust, which is not justifiable. Yours, Joel M. Halpern PS: The example that has helped me understand the weakness of transistive trust is the issue of source IP fitlering. it needs to be done a t the ingress ISP. ISPs can peer with only those other ISPs they trust. But it turns out no matter how you do it, some folks you need to trust end up choosing to trust other folks, who in turn don't do the filtering. At 11:44 AM 10/31/2006, Dean Willis wrote: >On Oct 31, 2006, at 6:20 AM, Joel M. Halpern wrote: > >>While we currently have the ability to demand security, we actually >>have no way to reliably know whether we got it. >>If we can not tell if it is being delivered, why is being able to >>ask for it better than expecting the system to always deliver it? >> > >I've been told it comes down to trust. You just don't use sips: to >talk to a proxy you don't trust to do the right thing. > >Common SIP deployment scenarios posit a high level of trust between >user and "home" or "outbound" proxy in many other ways. It is no >great leap to assume that a proxy you are trusting in all these other >ways will, if asked nicely, honor your request for "secure" >treatment. If you can't trust a proxy to do this for you, there's all >sorts of other stuff you can't trust it to do, and you probably >shouldn't be using it as a home or outbound proxy in a conventional >SIP deployment. > >I've been proposing changing SIP so that many of these assumptions >are no longer required, but in the absence of those changes, one >could reasonably argue that sips: is as strong as the rest of the >security model, because it's based on exactly the same trust >assumptions. Personally I take that more as an argument against the >current SIP security model than as an argument for the strength of >sips:, but one could work with it either way. > > >>PS: Just to be clear, the reason i say you can not tell if you got >>security is that even if we added extra recordings about what >>happens, I am pretty sure that two colluding proxies (such as a >>pair that have chosen to use IPSec instead of TLS, or have an old >>style telephony view and just trust their network and peering) will >>flat lie in order to deliver what they think is the service. > >Yep. That's a point a I think I've been asserting for quite some time. > >-- >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 Oct 31 17:07:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1jA-00063P-50; Tue, 31 Oct 2006 17:05:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1j7-00063K-Mt for sip@ietf.org; Tue, 31 Oct 2006 17:04:57 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1j5-0006RT-Fq for sip@ietf.org; Tue, 31 Oct 2006 17:04:57 -0500 Received: from [71.254.22.111] (helo=JMHLap3.stevecrocker.com) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Gf1j5-0000zT-Ba for sip@ietf.org; Tue, 31 Oct 2006 17:04:55 -0500 Message-Id: <7.0.1.0.0.20061031170136.0355fa10@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 31 Oct 2006 17:04:02 -0500 To: "IETF SIP List" From: "Joel M. Halpern" Subject: RE: [Sip] Re: What consensus? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0DC996EF@zrc2hxm0.corp.nor tel.com> References: <454784CF.3040602@cisco.com> <1ECE0EB50388174790F9694F77522CCF0DC996EF@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f083ca8aeb2d326d5a073bfd238dd844d2b10475b571120858b83b80a5943d1fb1d4849f639795710ec827ca34601a1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.254.22.111 X-Spam-Score: 0.1 (/) 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 Just to be clear, for the work item which says "document 3261 SIPS as defined, I believe Francois is correct, and I believe (if I have understood everything I have read properly) that his description is accurate. The fact that many people don't like it is irrelevant to that question. It is what it is. My concern is that the chartered work also includes making recommendations for where we should go. That is what I have been arguing on. At 12:48 PM 10/31/2006, Francois Audet wrote: >SHORT TERM: > >- We need to put a lid on inflated expectations of what SIPS really >means. > I favor a minimalistic interpretation of what SIPS means. The sooner >we > close that lid, the sooner we can move on to the LONG TERM. > >- This interpretation is in line with the spirit of RFC 3261. We are > trying first to "explain" RFC 3261, with it's limitations, in order to > > move on to something more comprehensive. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 Oct 31 17:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf27N-00073B-Sc; Tue, 31 Oct 2006 17:30:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf27J-0006xF-PO for sip@ietf.org; Tue, 31 Oct 2006 17:29:58 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf27H-0000jp-Qb for sip@ietf.org; Tue, 31 Oct 2006 17:29:57 -0500 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 k9VMTeX19009; Tue, 31 Oct 2006 17:29:40 -0500 (EST) 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] Re: What consensus? Date: Tue, 31 Oct 2006 16:29:35 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60F620799@zrc2hxm2.corp.nortel.com> In-Reply-To: <7.0.1.0.0.20061031170136.0355fa10@stevecrocker.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: What consensus? Thread-Index: Acb9OMpS4kpCKcmkT72rOR000qow/QAAPJeg From: "Samir Srivastava" To: "Joel M. Halpern" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 don't want to keep interworking with the broken stuff with the new Elegant or workable solution. Are we keep forgetting the nuisance of NAT interworking etc ? That will make the things more complex.=20 SIP itself is too complex. IMHO, the more complexities you add to the protocol, the less users you will get. See what major search engine chose ? People already started talking about mistakes of the SIP and paving the way for new protocol. Sometimes early adapters get the lead, and sometimes they are at the risk of implementing broken stuff. So it's that way only. Why IP surviving so long and being utilized for other purposes too? Because the founders had the UNWAVERING commitment to RUNNING CODE and they used to look for SIMPLICITY etc.. I don't want to go more details here. Talk to some of the providers and IT enterprise departments do they want to deploy SIPS in its current with patched form ? BTW what is the vote count?=20 Thx Samir > -----Original Message----- > From: Joel M. Halpern [mailto:joel@stevecrocker.com] > Sent: Tuesday, October 31, 2006 2:04 PM > To: IETF SIP List > Subject: RE: [Sip] Re: What consensus? >=20 > Just to be clear, for the work item which says "document 3261 SIPS as > defined, > I believe Francois is correct, and I believe (if I have understood > everything I have read properly) that his description is > accurate. The fact that many people don't like it is irrelevant to > that question. It is what it is. >=20 > My concern is that the chartered work also includes making > recommendations for where we should go. > That is what I have been arguing on. >=20 > At 12:48 PM 10/31/2006, Francois Audet wrote: > >SHORT TERM: > > > >- We need to put a lid on inflated expectations of what SIPS really > >means. > > I favor a minimalistic interpretation of what SIPS means. The sooner > >we > > close that lid, the sooner we can move on to the LONG TERM. > > > >- This interpretation is in line with the spirit of RFC 3261. We are > > trying first to "explain" RFC 3261, with it's limitations, in order to > > > > move on to something more comprehensive. >=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 Oct 31 22:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6QA-0001Oo-Ig; Tue, 31 Oct 2006 22:05:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6Q7-0001Oc-MF for sip@ietf.org; Tue, 31 Oct 2006 22:05:40 -0500 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf6Q5-0002KR-Ve for sip@ietf.org; Tue, 31 Oct 2006 22:05:39 -0500 Received: from [131.161.248.89] (open-131-161-248-89.cliq.com [131.161.248.89]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id kA1359229499; Tue, 31 Oct 2006 19:05:09 -0800 In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA101404514@ZMY16EXM67.ds.mot.com> References: <608D7BFF0D57794785CBC2C440BC4FA101404514@ZMY16EXM67.ds.mot.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <9ddfb92e99cc4c666a444a87e799d3b6@ekabal.com> Content-Transfer-Encoding: quoted-printable From: Rohan Mahy Date: Tue, 31 Oct 2006 19:05:20 -0800 To: "Vavilapalli Srikanth-A19563" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Cullen Cullen Jennings , Rohan Mahy , SIP List Subject: [Sip] Re: Questions on draft-ietf-sip-outbound-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Often comments or questions are sent to the relevant WG mailing list=20 (sip@ietf.org in this case), but questions to the authors is fine. I'm=20= cc:ing the list so that others can see the answers to your questions.=20 Answers inline. On Oct 31, 2006, at 5:06, Vavilapalli Srikanth-A19563 wrote: > Hi Jennings and Mahy > =C2=A0 > Not sure where to post my questions on this draft, hence mailing you=20= > directly. Please redirect me if this is not the=C2=A0way to put the=20 > questions. > =C2=A01. Can I send multiple REGISTER messages with different AOR and = same=20 > +sip.instance ID and reg-id on a single network flow? I have not seen=20= > any text in the draft preventing me from doing this, but just wanted=20= > to get clarified. I mean I have multiple SIP applications running on=20= > single device, so all applications will have same contact and have=20 > single TCP connection from the device to OB proxy. That should be fine. > =C2=A02. Page 13, Section 4.2: Why is this draft mandating to have = sets=20 > with atleast two outbound proxy URI? In a simple SIP network=20 > deployment scenario, where the "avalanche restart problem" is not an=20= > issue, Can't we have the set with single outbound proxy URI? The draft mandates that UAs can handle at least two URIs. This is to=20 insure interoperability between UAs and several kinds of networks. =20 Some of these will need avalanche restart protection. > 3. Page 13, Section 4.1:=C2=A0Can you give me an example of two = URNs=C2=A0which=20 > are functionally equivalent but lexigraphically different? When would=20= > clients send such URNs in multiple registrations, where they are=20 > functionally equal but not lexically? I=C2=A0assume=C2=A0UAs = always=C2=A0send same=20 > URN as +sip.instance value. Take two UUID URNs, one that uses uppercase hex digits and the other=20 that uses lowercase hex digits. In practice this will never happen as=20= long as the UA always sends the same string as the instance-id. > =C2=A04. Page 15, Section 4.4: "For UDP, the upper bound of 29 seconds = was=20 > selected so that multiple STUN packets could be sent before 30 seconds=20= > based on information that many NATs have UDP timeouts as low as 30=20 > seconds" - Can you please elaborate on this statement? Why/when would=20= > UA send multiple STUN packets before 30 seconds? STUN retransmissions will insure that if the first STUN query fails at=20= 29 seconds, several of STUN's normal retransmissions will happen before=20= 30 seconds. > 5. Page 24, Section 8: "Unvalidated TCP or TLS over TCP flows, the=20 > connection over which STUN requests were sent MUST be closed" - Can't=20= > UA fall back to some other keep-alive mechanism (some CRLF=20 > messages)=C2=A0if the target is not validated for STUN support on a = newly=20 > established TCP flow? No, because sending the STUN message over TCP will desynchronize the=20 TCP framing if the UA can't handle STUN on the same stream. You'll=20 have to open a new connection, but can then do CRLF or TCP keepalives=20 on the new connection. > Why would the STUN failure trigger TCP connection closure? > =E2=80=A2 If STUN support explicitly indicated > =E2=97=A6 Validate the STUN support using explicit probe > =E2=97=A6 If STUN support is validated > =E2=96=AA Mark the STUN support on that flow is validated > =E2=97=A6 Else /* Explicit probing failed */ > =E2=96=AA Fallback to some other keep alive mechanism like = CRLF instead of=20 > closing the TCP connection > =E2=80=A2 Else /* No STUN support indicated */ > =E2=97=A6 Use some other mechanism to keep alive the hole = (Ex. send a CRLF=20 > packet) > =C2=A0 > 6. Page 26, Section 9: In the given example, UAC first sends the=20 > request to primary and on receiving ICMP error it tries with=20 > secondary. That means we expect the calling UAs (callers) to be=20 > compliant with this draft or is this mechanism supported in RFC 3261=20= > itself? I'm not sure I know what you mean. There is a lot of behavior=20 described in RFC 3263 (which RFC 3261 says each implementation MUST=20 implement). Failover based on SRV records is in RFC 3263. Trying to=20 setup registrations with a primary and secondary because each is in the=20= outbound-proxy-set is new in outbound. thanks, -rohan > Appreciate your help in this regard. > =C2=A0 > Thanks&Regards > Srikanth= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip