From sip-bounces@ietf.org Mon May 01 12:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fabhz-00080X-Lu; Mon, 01 May 2006 12:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fabhx-00080S-CU for sip@ietf.org; Mon, 01 May 2006 12:57:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fabhx-0003Hf-5J for sip@ietf.org; Mon, 01 May 2006 12:57:13 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k41GvCvQ011260; Mon, 1 May 2006 16:57:12 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 12:57:12 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 May 2006 12:57:11 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597054F440C@stntexch03.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Identity and RFC 3893 Thread-Index: AcZjnWn9uPfoSxLXSg+sbzj0NI0BTQAODYZgAloNMDA= From: "Peterson, Jon" To: "Francois Audet" , X-OriginalArrivalTime: 01 May 2006 16:57:12.0444 (UTC) FILETIME=[4AA723C0:01C66D40] X-Spam-Score: -2.8 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Sip] RE: SIP Identity and RFC 3893 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 short answer is no, I don't think so. In part this is because there = is a need for third-party authentication for mechanisms like Referred-By = (RFC3892), and it's not at all clear that sip-identity could be adapted = to those needs. Speaking more to S/MIME in general, although = sip-identity provides an integrity property for SIP message bodies, it = doesn't provide a confidentiality property. There are a few significant = use cases today that still require confidentiality for SIP message = bodies, notably some of our media security schemes. Pending some of the = work in play on the rtpsec list, of course, that particular need could = change over time. But I certainly wouldn't say that we're in a position = to deprecate S/MIME yet. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, April 19, 2006 10:35 AM > To: sip@ietf.org; Peterson, Jon > Subject: SIP Identity and RFC 3893 >=20 >=20 > Jon, >=20 > Does sip-identity-06 make RFC 3893 (the AIB format for=20 > S/MIME) obsolete? >=20 > Sip-identity is remarkably silent about RFC 3893. It sorts of hints in = the=20 > introduction that sip-identity is an alternative to S/MIME, but it is = not > very specific. >=20 > The changelog (which will be removed upon publication) sheds a bit of = light > on the history behind this (i.e., in -01 we switched from AIB to new = header). >=20 > Should RFC 3893 (which is currently "Standards Track") be deprecated=20 > (moved to historical or whatever)? I'm kind of worried about = developper=20 > confusion between sip-identity and RFC 3893. >=20 > Also, to add a little more confusion to this, there is "normative" = reference > to RFC 3893 in sip-identity which, it seems to me, should be = "informative". >=20 > ---- > Fran=E7ois AUDET, Nortel Networks > mailto:audet@nortel.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 Mon May 01 13:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fac5B-0000sC-4J; Mon, 01 May 2006 13:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fac59-0000s7-DF for sip@ietf.org; Mon, 01 May 2006 13:21:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fac58-0003gL-34 for sip@ietf.org; Mon, 01 May 2006 13:21:11 -0400 Received: from [192.168.2.104] (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 k41HM679007041 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 1 May 2006 12:22:07 -0500 Mime-Version: 1.0 (Apple Message framework v749.3) References: <4456283A.5030603@isoc.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58A8022C-34E7-4A3D-A016-2AA40C497459@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 1 May 2006 12:21:27 -0500 To: SIP WG X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] IETF Meeting Survey for IETF 65 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ray Pelletier (IETF administrative director) and team have put together a survey relating to the IETF 65 experience, and would appreciate additional input. It takes about 5 min to complete (just did it myself). http://www.surveymonkey.com/s.asp?u=649182049947 -- 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 May 01 14:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Facgj-0008Iv-Hv; Mon, 01 May 2006 14:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Facgi-0008Iq-8v for sip@ietf.org; Mon, 01 May 2006 14:00:00 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Facgg-0005BA-Rg for sip@ietf.org; Mon, 01 May 2006 14:00:00 -0400 Received: (qmail 20324 invoked by uid 0); 1 May 2006 17:59:55 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 May 2006 17:59:55 -0000 Message-ID: <002401c66d49$0ac4aee0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Mon, 1 May 2006 19:59:50 +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.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Sip] dialog state model for SUBSCRIBE / NOTIFY usages X-BeenThere: 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="===============1789318001==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1789318001== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C66D59.CE16B770" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C66D59.CE16B770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC4235 defines a dialog state model for INVITE usages, and explicitly = declares non-session dialogs out of scope Two questions: 1) is any work planned for a definition of the dialog state model for = non-INVITE usages? 2) For SUBSCRIBE/NOTIFY, it would appear that a mapping is possible. In = the common case (assuming no 1xx responses) the Subscriber would move = from TRYING to CONFIRMED upon reception of 2xx to SUBSCRIBE, and the = notifier from TRYING to CONFIRMED upon sending the 2xx response to = SUBSCRIBE. Any thoughts on this? Regards, Jeroen ------=_NextPart_000_0021_01C66D59.CE16B770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC4235 defines a dialog state model = for INVITE=20 usages, and explicitly declares non-session dialogs out of = scope
 
Two questions:
1) is any work planned for a definition = of the=20 dialog state model for non-INVITE usages?
2) For SUBSCRIBE/NOTIFY, it would = appear that a=20 mapping is possible. In the common case (assuming no 1xx responses) the=20 Subscriber would move from TRYING to CONFIRMED upon reception of 2xx to=20 SUBSCRIBE, and the notifier from TRYING to CONFIRMED upon sending the = 2xx=20 response to SUBSCRIBE. Any thoughts on this?
 
Regards,
 
Jeroen
------=_NextPart_000_0021_01C66D59.CE16B770-- --===============1789318001== 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 --===============1789318001==-- From sip-bounces@ietf.org Mon May 01 15:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaePJ-0002lV-Vl; Mon, 01 May 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaePC-0002d3-B9; Mon, 01 May 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaePB-0001RC-S5; Mon, 01 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k41Jo10e020186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FaePB-0000ep-Ee; Mon, 01 May 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, 01 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-gruu-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 : 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-07.txt Pages : 36 Date : 2006-5-1 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a server and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-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-gruu-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-gruu-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-5-1135725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-1135725.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Tue May 02 02:56:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faom1-0002uA-8U; Tue, 02 May 2006 02:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faoly-0002tN-HB for sip@ietf.org; Tue, 02 May 2006 02:54:14 -0400 Received: from plmler2.mail.eds.com ([199.228.142.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoiS-00031S-Bl for sip@ietf.org; Tue, 02 May 2006 02:50:37 -0400 Received: from plmlir2.mail.eds.com (plmlir2-2.mail.eds.com [199.228.142.132]) by plmler2.mail.eds.com (8.13.6/8.12.10) with ESMTP id k426l1HO016269; Tue, 2 May 2006 01:47:02 -0500 Received: from plmlir2.mail.eds.com (localhost [127.0.0.1]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id k426k2O9009129; Tue, 2 May 2006 01:46:02 -0500 Received: from usut001.3com.com ([205.142.126.149]) by plmlir2.mail.eds.com (8.13.4/8.12.10) with ESMTP id k426k2Cw009113; Tue, 2 May 2006 01:46:02 -0500 To: sip-implementors@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Udit_Goyal@3com.com Date: Tue, 2 May 2006 13:18:19 +0630 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/01/2006 11:46:02 PM, Serialize complete at 05/01/2006 11:46:02 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org Subject: [Sip] Question regarding ptime attribute X-BeenThere: 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="===============0703709651==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0703709651== Content-Type: multipart/alternative; boundary="=_alternative 00256220E5257162_=" This is a multipart message in MIME format. --=_alternative 00256220E5257162_= Content-Type: text/plain; charset="US-ASCII" Hi, If SDP contains following media line data: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 a=ptime: 30 Does it mean that it is using 30 ms packetization period for all the audio codecs, or only for codec with PT=98, rest all codecs use 20 ms. -Udit --=_alternative 00256220E5257162_= Content-Type: text/html; charset="US-ASCII"
Hi,

If SDP contains following media line data:

m=audio 49230 RTP/AVP 96 97 98
 a=rtpmap:96 L8/8000
 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=ptime: 30

Does it mean that it is using 30 ms packetization period for all the audio codecs, or only for codec with PT=98, rest all codecs use 20 ms.

-Udit --=_alternative 00256220E5257162_=-- --===============0703709651== 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 --===============0703709651==-- From sip-bounces@ietf.org Tue May 02 04:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqFr-0006Bc-HW; Tue, 02 May 2006 04:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqFo-00061E-Si for sip@ietf.org; Tue, 02 May 2006 04:29:08 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaqFn-0006We-Au for sip@ietf.org; Tue, 02 May 2006 04:29:08 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k428Sw2C023921; Tue, 2 May 2006 10:28:58 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k428SwC2031115; Tue, 2 May 2006 10:28:58 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 10:28:58 +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 Subject: [Sip] Minor comments on draft-ietf-sip-gruu-07.txt Date: Tue, 2 May 2006 10:28:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Minor comments on draft-ietf-sip-gruu-07.txt Thread-Index: AcZtWH3Z0glBMArXQSWzt/HOqDPTHgAaVLWg From: "Tan, Ya-Ching" To: X-OriginalArrivalTime: 02 May 2006 08:28:58.0066 (UTC) FILETIME=[75001320:01C66DC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 - Section 10 Grammar does not mention the new "+sip.instance" parameter for the Contact header, but includes : instance-val =3D *uric ; defined in RFC 2396 (should be RFC 3986) - The SUBSCRIBE message on page 27 and page 28 : o The URI in the To header field must be enclosed in "<" and ">". As it is now, the "opaque" and "grid" become To header parameters. o Allow: INVITE, OPTIONS, CANCEL, BYE, ACK should also include=20 SUBSCRIBE and NOTIFY - Page 5 : ">From" should be "From" - Page 12 : "reuqest" should be "request" - Section 7.1.1.1 : "..., it MUST use [14]" =3D> "..., it MUST follow = the procedures defined in [14]". - Section 8.2.1 "(allowing mutiple flows.." has no closing bracket. - Section 8.2.3 "(which happens when the client.." has no closing bracket. - The last sentence on page 21 makes no sense. "This information may be present from the hint if the topmost Route header field URI, if the proxy used that technique". - Request-URI has been written as "Request URI", "request URI" (eg. 8.1.3 "the incoming request URI") as well as "Request-URI" throughout the document. - And we have "AOR" and "AoR" - Section 14 should register "Predefined Values : None" for all the new parameters. Regards, Ya-Ching _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 02 05:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqnT-0004T0-0S; Tue, 02 May 2006 05:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaqnR-0004RI-3w for sip@ietf.org; Tue, 02 May 2006 05:03:53 -0400 Received: from ahmler6.mail.eds.com ([192.85.154.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaqnP-0000AM-RJ for sip@ietf.org; Tue, 02 May 2006 05:03:53 -0400 Received: from ahmlir5.mail.eds.com (ahmlir5-2.mail.eds.com [192.85.154.135]) by ahmler6.mail.eds.com (8.13.6/8.12.10) with ESMTP id k42905wD023040; Tue, 2 May 2006 05:00:06 -0400 Received: from ahmlir5.mail.eds.com (localhost [127.0.0.1]) by ahmlir5.mail.eds.com (8.13.6/8.12.10) with ESMTP id k428x79F028381; Tue, 2 May 2006 04:59:07 -0400 Received: from usut001.3com.com ([205.142.126.149]) by ahmlir5.mail.eds.com (8.13.6/8.12.10) with ESMTP id k428x7kb028375; Tue, 2 May 2006 04:59:07 -0400 To: "sip list" <0xL1FFzsip-implementors@cs.columbia.edu> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Udit_Goyal@3com.com Date: Tue, 2 May 2006 14:31:25 +0530 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/02/2006 01:59:07 AM, Serialize complete at 05/02/2006 01:59:07 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org Subject: [Sip] ptime attribute in Offer SDP X-BeenThere: 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="===============0121471177==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0121471177== Content-Type: multipart/alternative; boundary="=_alternative 003191B465257162_=" This is a multipart message in MIME format. --=_alternative 003191B465257162_= Content-Type: text/plain; charset="US-ASCII" Hi, How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec, For example: For codec L8 if it supports both 20 and 30 ms ptime values, For codec L16, it supports 40 ms Is following media line is allowed? m=audio 49230 RTP/AVP 96 97 a=rtpmap:96 L8/8000 a=ptime: 20 a=ptime:30 a=rtpmap:97 L16/8000 a=ptime:40 And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute. -Udit --=_alternative 003191B465257162_= Content-Type: text/html; charset="US-ASCII"
Hi,

How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec,

For example:
For codec L8 if it supports both 20 and 30 ms ptime values,
For codec L16, it supports 40 ms

Is following media line is allowed?

m=audio 49230 RTP/AVP 96 97
a=rtpmap:96 L8/8000
a=ptime: 20
a=ptime:30
a=rtpmap:97 L16/8000
a=ptime:40

And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Udit_Goyal@3com.com Date: Tue, 2 May 2006 14:31:25 +0530 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 05/02/2006 01:59:07 AM, Serialize complete at 05/02/2006 01:59:07 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org Subject: [Sip] ptime attribute in Offer SDP X-BeenThere: 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="===============0121471177==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0121471177== Content-Type: multipart/alternative; boundary="=_alternative 003191B465257162_=" This is a multipart message in MIME format. --=_alternative 003191B465257162_= Content-Type: text/plain; charset="US-ASCII" Hi, How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec, For example: For codec L8 if it supports both 20 and 30 ms ptime values, For codec L16, it supports 40 ms Is following media line is allowed? m=audio 49230 RTP/AVP 96 97 a=rtpmap:96 L8/8000 a=ptime: 20 a=ptime:30 a=rtpmap:97 L16/8000 a=ptime:40 And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute. -Udit --=_alternative 003191B465257162_= Content-Type: text/html; charset="US-ASCII"
Hi,

How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec,

For example:
For codec L8 if it supports both 20 and 30 ms ptime values,
For codec L16, it supports 40 ms

Is following media line is allowed?

m=audio 49230 RTP/AVP 96 97
a=rtpmap:96 L8/8000
a=ptime: 20
a=ptime:30
a=rtpmap:97 L16/8000
a=ptime:40

And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute.

-Udit

--=_alternative 003191B465257162_=-- --===============0121471177== 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 --===============0121471177==-- From sip-bounces@ietf.org Tue May 02 05:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faqnd-0004W7-LI; Tue, 02 May 2006 05:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faqnc-0004Vz-0Z for sip@ietf.org; Tue, 02 May 2006 05:04:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faqnb-0000Am-He for sip@ietf.org; Tue, 02 May 2006 05:04:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4293xht026184; Tue, 2 May 2006 12:04:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:03:40 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:03:40 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 12:03:38 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02405CB2@esebe103.NOE.Nokia.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF092042EC@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZq3MA0Ialesbo2QrS++qPHWYUgLgAAaMcQALn0ufA= From: To: , , X-OriginalArrivalTime: 02 May 2006 09:03:40.0076 (UTC) FILETIME=[4DF996C0:01C66DC7] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I do not really have a strong opinion on this but can anyone point out the reason of having RFC 3263 as a separate document and not integrated to RFC 3261 ? Both were created at the same time and RFC 3261 relies on 3263 but they still remained as separate. Understanding the reasons for that better would enable us to check if they also apply to this. Logically I would think that having two separate specs would be clearer in a way that Outbound would update RFC 3261 while Outbound-discovery would update RFC 3263 instead of bundling all that together into one single atomic document. But like mentioned, if there are good reasons for integrating those documents then why not (at least after reaching stable enough consensus about the mechanisms used for discovery). Regards, Erkki=20 >-----Original Message----- >From: ext Francois Audet [mailto:audet@nortel.com]=20 >Sent: 28.April.2006 19:13 >To: Juha Heinanen; Dean Willis >Cc: SIP WG >Subject: RE: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >If we are happyt>

-Udit

--=_alternative 003191B465257162_=-- --===============0121471177== 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 --===============0121471177==-- From sip-bounces@ietf.org Tue May 02 05:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faqnd-0004W7-LI; Tue, 02 May 2006 05:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faqnc-0004Vz-0Z for sip@ietf.org; Tue, 02 May 2006 05:04:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faqnb-0000Am-He for sip@ietf.org; Tue, 02 May 2006 05:04:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4293xht026184; Tue, 2 May 2006 12:04:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:03:40 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 12:03:40 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 12:03:38 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02405CB2@esebe103.NOE.Nokia.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF092042EC@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZq3MA0Ialesbo2QrS++qPHWYUgLgAAaMcQALn0ufA= From: To: , , X-OriginalArrivalTime: 02 May 2006 09:03:40.0076 (UTC) FILETIME=[4DF996C0:01C66DC7] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I do not really have a strong opinion on this but can anyone point out the reason of having RFC 3263 as a separate document and not integrated to RFC 3261 ? Both were created at the same time and RFC 3261 relies on 3263 but they still remained as separate. Understanding the reasons for that better would enable us to check if they also apply to this. Logically I would think that having two separate specs would be clearer in a way that Outbound would update RFC 3261 while Outbound-discovery would update RFC 3263 instead of bundling all that together into one single atomic document. But like mentioned, if there are good reasons for integrating those documents then why not (at least after reaching stable enough consensus about the mechanisms used for discovery). Regards, Erkki=20 >-----Original Message----- >From: ext Francois Audet [mailto:audet@nortel.com]=20 >Sent: 28.April.2006 19:13 >To: Juha Heinanen; Dean Willis >Cc: SIP WG >Subject: RE: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >If we are happy with it, and it is normative, then why don't=20 >we just integrate this draft into sip-outbound? I see no >advantage to have it a separate draft. > >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com]=20 >> Sent: Friday, April 28, 2006 08:59 >> To: Dean Willis >> Cc: SIP WG >> Subject: Re: [Sip] I-D=20 >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >>=20 >>=20 >> Dean Willis writes: >>=20 >> > 1) Are we basically happy with this approach? >>=20 >> at least i'm happy. >> >=20 >> > 2) Do we need to include a reference to this in Outbound?=20 >> If so, is =20 >> > an informative reference adequate? >>=20 >> no, the reference MUST be at the same level as rfc3261=20 >> references rfc3263. there is no difference. >>=20 >> -- juha >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current=20 >> sip Use sipping@ietf.org for new developments on the=20 >> application of sip >>=20 >>=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 with it, and it is normative, then why don't=20 >we just integrate this draft into sip-outbound? I see no >advantage to have it a separate draft. > >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com]=20 >> Sent: Friday, April 28, 2006 08:59 >> To: Dean Willis >> Cc: SIP WG >> Subject: Re: [Sip] I-D=20 >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >>=20 >>=20 >> Dean Willis writes: >>=20 >> > 1) Are we basically happy with this approach? >>=20 >> at least i'm happy. >> >=20 >> > 2) Do we need to include a reference to this in Outbound?=20 >> If so, is =20 >> > an informative reference adequate? >>=20 >> no, the reference MUST be at the same level as rfc3261=20 >> references rfc3263. there is no difference. >>=20 >> -- juha >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current=20 >> sip Use sipping@ietf.org for new developments on the=20 >> application of sip >>=20 >>=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 May 02 05:44:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarOW-0005DD-MS; Tue, 02 May 2006 05:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarOV-0005D8-BE for sip@ietf.org; Tue, 02 May 2006 05:42:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarOU-0001nz-FB for sip@ietf.org; Tue, 02 May 2006 05:42:11 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 858284F0001; Tue, 2 May 2006 11:42:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 11:42:07 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 11:42:06 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] ptime attribute in Offer SDP Date: Tue, 2 May 2006 11:42:06 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0E56@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] ptime attribute in Offer SDP Thread-Index: AcZtx2wmPUEtMaYsRdyIoBEaTtfIwAABGi6A From: "Christer Holmberg \(JO/LMF\)" To: , "sip list" <0xL1FFzsip-implementors@cs.columbia.edu> X-OriginalArrivalTime: 02 May 2006 09:42:06.0882 (UTC) FILETIME=[ACF04020:01C66DCC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============1770351193==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1770351193== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66DCC.AC718EAE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66DCC.AC718EAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The media line in your example is not allowed. The ptime attribute is not codec specific, it is given per media description (m=3D line). =20 The possibility to provide a ptime value for a specific codec has been discussed on the MMUSIC list. Different alternatives were discussed. One proposal was to define a new attribute. Another proposal was to use the "vsel" attribute, defined in RFC3108, which allows you to provide values per codecs. =20 Regards, =20 Christer =20 ________________________________ From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]=20 Sent: 2. toukokuuta 2006 12:01 To: sip list Cc: sip@ietf.org Subject: [Sip] ptime attribute in Offer SDP=20 Hi,=20 How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec,=20 For example:=20 For codec L8 if it supports both 20 and 30 ms ptime values,=20 For codec L16, it supports 40 ms=20 Is following media line is allowed?=20 m=3Daudio 49230 RTP/AVP 96 97=20 a=3Drtpmap:96 L8/8000=20 a=3Dptime: 20=20 a=3Dptime:30=20 a=3Drtpmap:97 L16/8000=20 a=3Dptime:40=20 And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute.=20 -Udit=20 ------_=_NextPart_001_01C66DCC.AC718EAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
The=20 media line in your example is not allowed. The ptime attribute is not = codec=20 specific, it is given per media description (m=3D = line).
 
The=20 possibility to provide a ptime value for a specific codec has been = discussed on=20 the MMUSIC list. Different alternatives were discussed. = One proposal was to=20 define a new attribute. Another proposal was to use the "vsel" = attribute,=20 defined in RFC3108, which allows you to provide values per=20 codecs.
 
Regards,
 
Christer
 

From: Udit_Goyal@3com.com=20 [mailto:Udit_Goyal@3com.com]
Sent: 2. toukokuuta 2006=20 12:01
To: sip list
Cc: = sip@ietf.org
Subject: [Sip]=20 ptime attribute in Offer SDP


Hi,

How can a UA publish its capabilities of = supporting=20 multiple packetization time support for a particular codec, =

For example:
For=20 codec L8 if it supports both 20 and 30 ms ptime values,
For codec L16, it supports 40 ms =

Is following media line is allowed? =

m=3Daudio 49230 RTP/AVP 96 97 =
a=3Drtpmap:96 L8/8000
a=3Dptime: 20
a=3Dptime:30=20
a=3Drtpmap:97 L16/8000 =
a=3Dptime:40

And is ptime attribute a property of whole media lines or only = for a=20 codec, I remember in earlier discussions it is a codec attribute. =

-Udit =

------_=_NextPart_001_01C66DCC.AC718EAE-- --===============1770351193== 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 --===============1770351193==-- From sip-bounces@ietf.org Tue May 02 06:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fas60-0000wX-4V; Tue, 02 May 2006 06:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fas5y-0000wS-IQ for sip@ietf.org; Tue, 02 May 2006 06:27:06 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fas5x-0003dn-Ub for sip@ietf.org; Tue, 02 May 2006 06:27:06 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42AR2A6011514; Tue, 2 May 2006 13:27:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 13:26:59 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 13:26:59 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 13:26:58 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02405D92@esebe103.NOE.Nokia.com> In-Reply-To: <00a601c66ae2$2d1398d0$91c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/AB01mMgA5NdxsABaqE4YAC6Ez+Q From: To: , X-OriginalArrivalTime: 02 May 2006 10:26:59.0167 (UTC) FILETIME=[F1AA56F0:01C66DD2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 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 am happy to see some discussion raised by my I-D, since=20 one aim for publishing the I-D was to get more focused comments on the autodiscovery topic. >why did you choose to use the SRV priority in that way?=20 >You said "choose one of each priority level". The reason for my choice was how draft-ietf-sip-outbound-03=20 is currently written (and the focus of my thoughts when writing the I-D). The chapter 3.3 Multiple Connections from a User Agent starts the discussion with introducing the primary and backup proxies using the following statements: The UA is configured with a primary and backup registration URI. The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the backup hosts. I was focusing my thinking about how to avoid the requirements of having different primary and backup URIs i.e: a) To configure the UA with two URIs (instead of a single one that could be got from DHCP or derived from the AOR of the user) b) To configure the DNS for primary and backup proxies so that=20 two "domains" would have to be used for each Actually RFC 2782 (SRV RR) also discusses primary and backup services: The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups. I just found it convenient to make a mapping between the concepts=20 used in these two specs in the way I did. So instead of the need to=20 separately configure "backup registration URI" to the UA, the SRV=20 records with higher numbers could be used as backup servers for=20 SIP Outbound. On the other hand my I-D is not explicit what comes to the scalability=20 and load balancing. My intention was to leave it as the responsibility of usual SRV RR processing as discussed within draft-ietf-sip-outbound-03. Note that each URI in the outbound-proxy-set could resolve to several different physical hosts. The administrative domain that created these URIs should ensure that the two URIs resolve to separate hosts. These URIs are handled according to normal SIP processing rules, so things like SRV can be used to do load balancing across a proxy farm. Scalability is achieved by using DNS SRV to load balance the primary connection across a set of machines that can service the primary connection and also using DNS SRV to load balance across a separate set of machines that can service the backup connection.=20 The approach for load balancing specified in RFC 2782 (SRV RR) is as follows: Priority The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field.=20 Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. In other words load balancing is achieved between multiple UAs, each of them randomly selecting one proxy amongst the ones defined within the highest priority SRV RR. One UA would ever use only one single primary proxy but if there are N primary proxies, then any of those would only serve 1/N of the whole UA population. My I-D was not supposed to change any of that, so it was not explicitely specified either. No load balancing between the primary and backup connection was planned for the UA, instead the load balancing is only done when selecting which primary and backup proxy to use: While there are still elements left at this priority level Select an element as specified above, in the description of Weight in "The format of the SRV RR" Section, and move it to the tail of the new list And now the real problem (which is actually an issue within draft-ietf-sip-outbound-03) is: if a single UA still needs a backup proxy (and a backup connection), shall those backup proxies be one of those the other UAs are using as their=20 primaries or should those backup proxies be totally separate from the primary proxy farm ? Currently draft-ietf-sip-outbound-03 seems to suggest having separate set of primary proxies and another set of backup proxies: The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the backup hosts. Designs having only one set were also considered, but in this case there would have to be some way to ensure that the two connection did not accidentally resolve to the same host.=20 If the agreement will be that no dedicated backup proxies should be used for SIP Outbound but instead one common set of proxies should be used both for load balancing and backup purposes then I would suggest: - Rewriting draft-ietf-sip-outbound-03 accordingly - Revising draft-koivusalo-sip-outbound-discovery-00 so that: * UA would use two proxies within the same SRV RR Priority level as primary and backup * Load balancing would still be done between the UAs (each of them selecting their primary proxy with SRV RR Weight and using the primary proxy whenever it responds) instead of requiring a single UA to distribute its traffic=20 proportionately to weight (which would complicate the UA implementation quite a lot). Comments ? Regards, Erkki=20 >-----Original Message----- >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >Sent: 28.April.2006 19:38 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org >Subject: RE: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >Hi Erkki, >I am confused by one thing (well, for this topic): why did you=20 >choose to use >the SRV priority in that way? You said "choose one of each=20 >priority level". >If I understand the outbound draft correctly, there is no real=20 >distinction >between primary and backups - any one of them can get new=20 >requests at any >time, and the UA registers to all. So they're really all=20 >primaries once the >UA chooses to create a flow to them. Thus I would think it=20 >more logical to >have a UA which supports outbound connect to all servers of=20 >the same and >lowest SRV priority if the server supported outbound, and only=20 >connect to >higher ones upon failure of lower ones. > >That way a higher priority really means "connect if lower one=20 >fails", as it >did for SRV before outbound. No? > >-hadriel > > >> -----Original Message----- >> From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >> Sent: Friday, April 21, 2006 7:34 AM >> To: sip@ietf.org >> Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- >> 00.txt >>=20 >> Hi, >>=20 >> >I made up two proposals based on DNS for the UA to find >> >out proxies supporting outbound within the domain of SIP >> >AOR of the user or the domain got from DHCP ... >> > >> >I am now planning to put together an I-D for those proposals >> >as an update to RFC 3263. It may take some time, but hopefully >> >not too long. >>=20 >> The promised I-D is now available: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Discovering Proxies Supporting SIP Outbound >> Author(s) : E. Koivusalo >> Filename : draft-koivusalo-sip-outbound-discovery-00.txt >> Pages : 17 >> Date : 2006-4-20 >>=20 >> This document describes modifications to DNS procedures used to >> resolve a SIP Uniform Resource Identifier (URI) into the=20 >IP address, >> port, and transport protocol of the next hop to contact. These >> modifications enable the SIP User Agent to discover those proxies, >> within the domain of the SIP URI, that support SIP extensions >> described in draft-ietf-sip-outbound document. The introduced >> mechanisms update behavior defined in RFC 3263. >>=20 >>=20 >> A URL for this Internet-Draft is: >>=20 >http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun >d-discove >> ry-00.txt >>=20 >> I would appreciate for anyone interested to review this spec >> and provide me with comments. >>=20 >> Regards, >>=20 >> Erkki >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 02 08:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fatom-0005fM-Qz; Tue, 02 May 2006 08:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fatok-0005fG-LQ for sip@ietf.org; Tue, 02 May 2006 08:17:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FasUP-0004rU-60 for sip@ietf.org; Tue, 02 May 2006 06:52:21 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FasNe-0000LT-9t for sip@ietf.org; Tue, 02 May 2006 06:45:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42AjIGi012940; Tue, 2 May 2006 13:45:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 13:45:18 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 13:45:18 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 13:45:17 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> In-Reply-To: <001401c665eb$782071f0$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZl64DSFr3Vo0KvTJahlDEFFykoxwH6GMQw From: To: , X-OriginalArrivalTime: 02 May 2006 10:45:18.0006 (UTC) FILETIME=[809FDD60:01C66DD5] X-Spam-Score: -2.3 (--) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 Jeroen, I am sorry that I have not been able to respond your suggestions before. I have been rather busy with my other assignment recently (and will continue so probably in next 1-2 weeks). I hope to be able to study your proposals within 2-3 weeks and tell if I find them feasible (or more feasible than those mechanisms that my I-D currently uses). This far you are only person who has expressed a strong concern about the DNS NAPTR record scalability while some others have been happy with the solution I proposed. So I would be grateful of the others to tell if they have similar worries, in order to estimate which way would be the best to go. What comes to the TXT records, I do not have any information about how widely they are currently supported. 15 years ago they were not, according to RFC 1123 that says: The TXT and WKS RR types have not been widely used by Internet sites; as a result, an application cannot rely on the the existence of a TXT or WKS RR in most domains.=20 Is this already obsolete ? Do everyone agree that TXT records could now safely be used for the SIP Outbound discovery solution ? Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 22.April.2006 12:02 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org >Subject: Re: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >Erkki, > >Another possibility: http://www.dns-sd.org/ServiceTypes.html lists the=20 >following TXT keys defined for the "sip" service (amongst others): > >sip Session Initiation Protocol, signalling=20 >protocol for VoIP > registrar SIP registrar (see RFC3261) > proxy SIP proxy (see RFC3261) > natproxy SIP proxy for NATed clients > outproxy outbound SIP proxy (see RFC3261) > stunserver STUN server DNS name or IP address > [Further TXT record keys may be added in the future.] > >We could define a new TXT record key, say "outbound", and=20 >return that along=20 >with the result of a SRV lookup. In other words: use DNS-SD=20 >(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for=20 >the purpose=20 >of outbound proxy discovery > >Regards, > >jeroen > >----- Original Message -----=20 >From: "Jeroen van Bemmel" >To: ; >Sent: Friday, April 21, 2006 7:43 PM >Subject: Re: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > >> Erkki, >> >> To me the draft too easily discards the "this is not=20 >scalable" argument.=20 >> It really is not scalable, and stacking features on DNS like=20 >this feels=20 >> wrong. >> >> RFC2915 hints at an alternative approach in the description=20 >of the usage=20 >> of the "U" flag: "[...] there may be applications that use=20 >NAPTR to also=20 >> lookup aspects of URIs". You could use a regular expression=20 >including a=20 >> flag that denotes outbound support. >> >> Regards, >> >> Jeroen >> >> ----- Original Message -----=20 >> From: >> To: >> Sent: Friday, April 21, 2006 1:34 PM >> Subject: RE: [Sip] I-D=20 >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >> >> >> Hi, >> >>>I made up two proposals based on DNS for the UA to find >>>out proxies supporting outbound within the domain of SIP >>>AOR of the user or the domain got from DHCP ... >>> >>>I am now planning to put together an I-D for those proposals >>>as an update to RFC 3263. It may take some time, but hopefully >>>not too long. >> >> The promised I-D is now available: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Discovering Proxies Supporting SIP Outbound >> Author(s) : E. Koivusalo >> Filename : draft-koivusalo-sip-outbound-discovery-00.txt >> Pages : 17 >> Date : 2006-4-20 >> >> This document describes modifications to DNS procedures used to >> resolve a SIP Uniform Resource Identifier (URI) into the=20 >IP address, >> port, and transport protocol of the next hop to contact. These >> modifications enable the SIP User Agent to discover those proxies, >> within the domain of the SIP URI, that support SIP extensions >> described in draft-ietf-sip-outbound document. The introduced >> mechanisms update behavior defined in RFC 3263. >> >> >> A URL for this Internet-Draft is: >>=20 >http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun >d-discove >> ry-00.txt >> >> I would appreciate for anyone interested to review this spec >> and provide me with comments. >> >> Regards, >> >> Erkki >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip=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 May 02 08:47:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauFj-0006VW-4H; Tue, 02 May 2006 08:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauFh-0006OB-5K for sip@ietf.org; Tue, 02 May 2006 08:45:17 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauFf-0001je-TF for sip@ietf.org; Tue, 02 May 2006 08:45:17 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k42CiQXF000469; Tue, 2 May 2006 07:44:27 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 May 2006 13:44:26 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012D51E92@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Udit_Goyal@3com.com, sip list <0xL1FFzsip-implementors@cs.columbia.edu> Subject: RE: [Sip] ptime attribute in Offer SDP Date: Tue, 2 May 2006 13:44:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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="===============0079698606==" 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. --===============0079698606== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66DE6.234BD6DA" 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_01C66DE6.234BD6DA Content-Type: text/plain Can you please make requests concerning SDP usage on the MMUSIC lists ( mmusic@ietf.org ) unless it impacts some aspect of the SIP protocol. regards Keith -----Original Message----- From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com] Sent: 02 May 2006 10:01 To: sip list Cc: sip@ietf.org Subject: [Sip] ptime attribute in Offer SDP Hi, How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec, For example: For codec L8 if it supports both 20 and 30 ms ptime values, For codec L16, it supports 40 ms Is following media line is allowed? m=audio 49230 RTP/AVP 96 97 a=rtpmap:96 L8/8000 a=ptime: 20 a=ptime:30 a=rtpmap:97 L16/8000 a=ptime:40 And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute. -Udit ------_=_NextPart_001_01C66DE6.234BD6DA Content-Type: text/html
Can you please make requests concerning SDP usage on the MMUSIC lists (mmusic@ietf.org) unless it impacts some aspect of the SIP protocol.
 
regards
 
Keith
-----Original Message-----
From: Udit_Goyal@3com.com [mailto:Udit_Goyal@3com.com]
Sent: 02 May 2006 10:01
To: sip list
Cc: sip@ietf.org
Subject: [Sip] ptime attribute in Offer SDP


Hi,

How can a UA publish its capabilities of supporting multiple packetization time support for a particular codec,

For example:
For codec L8 if it supports both 20 and 30 ms ptime values,
For codec L16, it supports 40 ms

Is following media line is allowed?

m=audio 49230 RTP/AVP 96 97
a=rtpmap:96 L8/8000
a=ptime: 20
a=ptime:30
a=rtpmap:97 L16/8000
a=ptime:40

And is ptime attribute a property of whole media lines or only for a codec, I remember in earlier discussions it is a codec attribute.

-Udit

------_=_NextPart_001_01C66DE6.234BD6DA-- --===============0079698606== 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 --===============0079698606==-- From sip-bounces@ietf.org Tue May 02 09:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavGX-0005GG-LD; Tue, 02 May 2006 09:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavGV-0005GB-Ue for sip@ietf.org; Tue, 02 May 2006 09:50:11 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavGV-0004pj-9h for sip@ietf.org; Tue, 02 May 2006 09:50:11 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 06:50:11 -0700 X-IronPort-AV: i="4.05,80,1146466800"; d="scan'208"; a="1800535881:sNHT34315860" 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 k42Do6VU001320; Tue, 2 May 2006 06:50:10 -0700 (PDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 09:50:07 -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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 09:50:06 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3016986BF@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZVFd0sG9YDgsEJEdqlkgARJEEJ/AB01mMgA5NdxsABaqE4YAC6Ez+QAAlocXA= From: "Michael Hammer \(mhammer\)" To: , , X-OriginalArrivalTime: 02 May 2006 13:50:07.0087 (UTC) FILETIME=[523B57F0:01C66DEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 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. What one UA uses as primary or backup proxies versus another UA should be totally independent and a matter of configuration. Don't build in unnecessary restrictions that just cause trouble down the road. Mike > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: Tuesday, May 02, 2006 6:27 AM > To: HKaplan@acmepacket.com; sip@ietf.org > Subject: RE: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >=20 > Hi, >=20 > I am happy to see some discussion raised by my I-D, since one=20 > aim for publishing the I-D was to get more focused comments=20 > on the autodiscovery topic. >=20 > >why did you choose to use the SRV priority in that way?=20 > >You said "choose one of each priority level". >=20 > The reason for my choice was how draft-ietf-sip-outbound-03=20 > is currently written (and the focus of my thoughts when=20 > writing the I-D). >=20 > The chapter 3.3 Multiple Connections from a User Agent starts=20 > the discussion with introducing the primary and backup=20 > proxies using the following statements: >=20 > The UA is configured with a primary and backup registration URI. >=20 > The deployment here requires > that DNS is configured with one entry that resolves to all the > primary hosts and another entry that resolves to all the backup > hosts. >=20 > I was focusing my thinking about how to avoid the=20 > requirements of having different primary and backup URIs i.e: >=20 > a) To configure the UA with two URIs (instead of a single one > that could be got from DHCP or derived from the AOR of the user) >=20 > b) To configure the DNS for primary and backup proxies so that=20 > two "domains" would have to be used for each >=20 > Actually RFC 2782 (SRV RR) also discusses primary and backup services: >=20 > The SRV RR allows administrators to use several servers=20 > for a single > domain, to move services from host to host with little fuss, and to > designate some hosts as primary servers for a service and others as > backups. >=20 > I just found it convenient to make a mapping between the=20 > concepts used in these two specs in the way I did. So instead=20 > of the need to separately configure "backup registration URI"=20 > to the UA, the SRV records with higher numbers could be used=20 > as backup servers for SIP Outbound. >=20 > On the other hand my I-D is not explicit what comes to the=20 > scalability and load balancing. My intention was to leave it=20 > as the responsibility of usual SRV RR processing as discussed=20 > within draft-ietf-sip-outbound-03. >=20 > Note that each URI > in the outbound-proxy-set could resolve to several=20 > different physical > hosts. The administrative domain that created these URIs should > ensure that the two URIs resolve to separate hosts. These URIs are > handled according to normal SIP processing rules, so=20 > things like SRV > can be used to do load balancing across a proxy farm. >=20 > Scalability > is achieved by using DNS SRV to load balance the primary connection > across a set of machines that can service the primary=20 > connection and > also using DNS SRV to load balance across a separate set=20 > of machines > that can service the backup connection.=20 >=20 > The approach for load balancing specified in RFC 2782 (SRV RR) is as > follows: >=20 > Priority > The priority of this target host. A client MUST attempt to > contact the target host with the lowest-numbered=20 > priority it can > reach; target hosts with the same priority SHOULD be=20 > tried in an > order defined by the weight field.=20 >=20 > Weight > A server selection mechanism. The weight field specifies a > relative weight for entries with the same priority. Larger > weights SHOULD be given a proportionately higher=20 > probability of > being selected. >=20 > In other words load balancing is achieved between multiple=20 > UAs, each of them randomly selecting one proxy amongst the=20 > ones defined within the highest priority SRV RR. One UA would=20 > ever use only one single primary proxy but if there are N=20 > primary proxies, then any of those would only serve 1/N of=20 > the whole UA population. My I-D was not supposed to change=20 > any of that, so it was not explicitely specified either. No=20 > load balancing between the primary and backup connection was=20 > planned for the UA, instead the load balancing is only done=20 > when selecting which primary and backup proxy to use: >=20 > While there are still elements left at this priority > level >=20 > Select an element as specified above, in the > description of Weight in "The format of the SRV > RR" Section, and move it to the tail of the new > list >=20 > And now the real problem (which is actually an issue within > draft-ietf-sip-outbound-03) is: if a single UA still needs a=20 > backup proxy (and a backup connection), shall those backup=20 > proxies be one of those the other UAs are using as their=20 > primaries or should those backup proxies be totally separate=20 > from the primary proxy farm ? Currently=20 > draft-ietf-sip-outbound-03 seems to suggest having separate=20 > set of primary proxies and another set of backup proxies: >=20 > The deployment here requires > that DNS is configured with one entry that resolves to all the > primary hosts and another entry that resolves to all the backup > hosts. Designs having only one set were also considered,=20 > but in this > case there would have to be some way to ensure that the two > connection did not accidentally resolve to the same host.=20 >=20 > If the agreement will be that no dedicated backup proxies=20 > should be used for SIP Outbound but instead one common set of=20 > proxies should be used both for load balancing and backup=20 > purposes then I would > suggest: >=20 > - Rewriting draft-ietf-sip-outbound-03 accordingly >=20 > - Revising draft-koivusalo-sip-outbound-discovery-00 so that: >=20 > * UA would use two proxies within the same SRV RR Priority > level as primary and backup >=20 > * Load balancing would still be done between the UAs (each > of them selecting their primary proxy with SRV RR Weight > and using the primary proxy whenever it responds) instead > of requiring a single UA to distribute its traffic=20 > proportionately to weight (which would complicate the UA > implementation quite a lot). >=20 > Comments ? >=20 > Regards, >=20 > Erkki=20 >=20 > >-----Original Message----- > >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >Sent: 28.April.2006 19:38 > >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org > >Subject: RE: [Sip] I-D > >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > >Hi Erkki, > >I am confused by one thing (well, for this topic): why did=20 > you choose=20 > >to use the SRV priority in that way? You said "choose one of each=20 > >priority level". > >If I understand the outbound draft correctly, there is no real=20 > >distinction between primary and backups - any one of them=20 > can get new=20 > >requests at any time, and the UA registers to all. So=20 > they're really=20 > >all primaries once the UA chooses to create a flow to them. Thus I=20 > >would think it more logical to have a UA which supports outbound=20 > >connect to all servers of the same and lowest SRV priority if the=20 > >server supported outbound, and only connect to higher ones=20 > upon failure=20 > >of lower ones. > > > >That way a higher priority really means "connect if lower=20 > one fails",=20 > >as it did for SRV before outbound. No? > > > >-hadriel > > > > > >> -----Original Message----- > >> From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] > >> Sent: Friday, April 21, 2006 7:34 AM > >> To: sip@ietf.org > >> Subject: RE: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery- > >> 00.txt > >>=20 > >> Hi, > >>=20 > >> >I made up two proposals based on DNS for the UA to find=20 > out proxies=20 > >> >supporting outbound within the domain of SIP AOR of the=20 > user or the=20 > >> >domain got from DHCP ... > >> > > >> >I am now planning to put together an I-D for those=20 > proposals as an=20 > >> >update to RFC 3263. It may take some time, but hopefully not too=20 > >> >long. > >>=20 > >> The promised I-D is now available: > >>=20 > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories. > >>=20 > >>=20 > >> Title : Discovering Proxies Supporting SIP Outbound > >> Author(s) : E. Koivusalo > >> Filename : draft-koivusalo-sip-outbound-discovery-00.txt > >> Pages : 17 > >> Date : 2006-4-20 > >>=20 > >> This document describes modifications to DNS procedures used to > >> resolve a SIP Uniform Resource Identifier (URI) into the > >IP address, > >> port, and transport protocol of the next hop to contact. These > >> modifications enable the SIP User Agent to discover=20 > those proxies, > >> within the domain of the SIP URI, that support SIP extensions > >> described in draft-ietf-sip-outbound document. The introduced > >> mechanisms update behavior defined in RFC 3263. > >>=20 > >>=20 > >> A URL for this Internet-Draft is: > >>=20 > >http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun > >d-discove > >> ry-00.txt > >>=20 > >> I would appreciate for anyone interested to review this spec and=20 > >> provide me with comments. > >>=20 > >> Regards, > >>=20 > >> Erkki > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > > > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=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 May 02 10:06:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavUO-0006AV-TY; Tue, 02 May 2006 10:04:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavUO-0006AF-8A for sip@ietf.org; Tue, 02 May 2006 10:04:32 -0400 Received: from ausmtp04.au.ibm.com ([202.81.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavUL-0005E6-Ic for sip@ietf.org; Tue, 02 May 2006 10:04:32 -0400 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp04.au.ibm.com (8.13.6/8.13.5) with ESMTP id k42EEpE8293560 for ; Wed, 3 May 2006 00:14:51 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k42E7kdi231102 for ; Wed, 3 May 2006 00:07:46 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id k42E4Qw7021707 for ; Wed, 3 May 2006 00:04:26 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id k42E4PXL021577 for ; Wed, 3 May 2006 00:04:26 +1000 From: Xin Sheng Mao To: sip@ietf.org Message-ID: Date: Tue, 2 May 2006 22:06:57 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0HF124 | January 12, 2006) at 05/02/2006 22:07:04 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Xin Sheng Mao/China/IBM 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: , Content-Type: multipart/mixed; boundary="===============1122918898==" Errors-To: sip-bounces@ietf.org --===============1122918898== Content-type: multipart/alternative; Boundary="0__=C7BBFBF1DFDE0CF78f9e8a93df938690918cC7BBFBF1DFDE0CF7" Content-Disposition: inline --0__=C7BBFBF1DFDE0CF78f9e8a93df938690918cC7BBFBF1DFDE0CF7 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 05/01/2006 and will not return until 05/07/2006. I am out of office for Spring Festival, ie., Chinese New Year, till Feb. 5th. Pls access me at my cell phone if you have any urgency. --0__=C7BBFBF1DFDE0CF78f9e8a93df938690918cC7BBFBF1DFDE0CF7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 05/01/2006 and will not return until 05/07/2006.

I am out of office for Spring Festival, ie., Chinese New Year, till Feb. 5th. Pls access me at my cell phone if you have any urgency. --0__=C7BBFBF1DFDE0CF78f9e8a93df938690918cC7BBFBF1DFDE0CF7-- --===============1122918898== 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 --===============1122918898==-- From sip-bounces@ietf.org Tue May 02 10:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaveM-0002JM-EC; Tue, 02 May 2006 10:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaveK-0002JH-Qg for sip@ietf.org; Tue, 02 May 2006 10:14:48 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaveJ-0005PS-JT for sip@ietf.org; Tue, 02 May 2006 10:14:48 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc12) with SMTP id <20060502141446m1200cqndie>; Tue, 2 May 2006 14:14:46 +0000 Message-ID: <055e01c66df2$c90be130$0600a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <072C5B76F7CEAB488172C6F64B30B5E3016986BF@xmb-rtp-20b.amer.cisco.com> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 09:14:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Definitely agree with Mike here. Spencer From: "Michael Hammer (mhammer)" To: ; ; Sent: Tuesday, May 02, 2006 8:50 AM Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Hi. What one UA uses as primary or backup proxies versus another UA should be totally independent and a matter of configuration. Don't build in unnecessary restrictions that just cause trouble down the road. 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 May 02 13:53:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faz2A-0001Xo-6q; Tue, 02 May 2006 13:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faz29-0001Xj-Kd for sip@ietf.org; Tue, 02 May 2006 13:51:37 -0400 Received: from smtp1.versatel.nl ([62.58.50.88] helo=smtp3.versatel.nl) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faz28-0007PR-0j for sip@ietf.org; Tue, 02 May 2006 13:51:37 -0400 Received: (qmail 12095 invoked by uid 0); 2 May 2006 17:51:31 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2006 17:51:31 -0000 Message-ID: <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 19:51:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 Erkki, Indeed, the extend of support for TEXT records or DNS-SD remains to be determined also for me. Apparently the IETF once had a workinggroup for this (http://www.zeroconf.org/) but apparently they felt that their work was finished several years ago. I think we all agree that "a DNS-based solution" is required/acceptable. Now all that remains is to work out the details. Perhaps someone could do a quick test on a current DNS server, to see how difficult it is to add a TEXT record, and what a client would get? Regards, Jeroen ----- Original Message ----- From: To: ; Sent: Tuesday, May 02, 2006 12:45 PM Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Hi Jeroen, I am sorry that I have not been able to respond your suggestions before. I have been rather busy with my other assignment recently (and will continue so probably in next 1-2 weeks). I hope to be able to study your proposals within 2-3 weeks and tell if I find them feasible (or more feasible than those mechanisms that my I-D currently uses). This far you are only person who has expressed a strong concern about the DNS NAPTR record scalability while some others have been happy with the solution I proposed. So I would be grateful of the others to tell if they have similar worries, in order to estimate which way would be the best to go. What comes to the TXT records, I do not have any information about how widely they are currently supported. 15 years ago they were not, according to RFC 1123 that says: The TXT and WKS RR types have not been widely used by Internet sites; as a result, an application cannot rely on the the existence of a TXT or WKS RR in most domains. Is this already obsolete ? Do everyone agree that TXT records could now safely be used for the SIP Outbound discovery solution ? Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >Sent: 22.April.2006 12:02 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org >Subject: Re: [Sip] I-D >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > >Erkki, > >Another possibility: http://www.dns-sd.org/ServiceTypes.html lists the >following TXT keys defined for the "sip" service (amongst others): > >sip Session Initiation Protocol, signalling >protocol for VoIP > registrar SIP registrar (see RFC3261) > proxy SIP proxy (see RFC3261) > natproxy SIP proxy for NATed clients > outproxy outbound SIP proxy (see RFC3261) > stunserver STUN server DNS name or IP address > [Further TXT record keys may be added in the future.] > >We could define a new TXT record key, say "outbound", and >return that along >with the result of a SRV lookup. In other words: use DNS-SD >(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for >the purpose >of outbound proxy discovery > >Regards, > >jeroen > >----- Original Message ----- >From: "Jeroen van Bemmel" >To: ; >Sent: Friday, April 21, 2006 7:43 PM >Subject: Re: [Sip] I-D >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > >> Erkki, >> >> To me the draft too easily discards the "this is not >scalable" argument. >> It really is not scalable, and stacking features on DNS like >this feels >> wrong. >> >> RFC2915 hints at an alternative approach in the description >of the usage >> of the "U" flag: "[...] there may be applications that use >NAPTR to also >> lookup aspects of URIs". You could use a regular expression >including a >> flag that denotes outbound support. >> >> Regards, >> >> Jeroen >> >> ----- Original Message ----- >> From: >> To: >> Sent: Friday, April 21, 2006 1:34 PM >> Subject: RE: [Sip] I-D >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >> >> >> Hi, >> >>>I made up two proposals based on DNS for the UA to find >>>out proxies supporting outbound within the domain of SIP >>>AOR of the user or the domain got from DHCP ... >>> >>>I am now planning to put together an I-D for those proposals >>>as an update to RFC 3263. It may take some time, but hopefully >>>not too long. >> >> The promised I-D is now available: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Discovering Proxies Supporting SIP Outbound >> Author(s) : E. Koivusalo >> Filename : draft-koivusalo-sip-outbound-discovery-00.txt >> Pages : 17 >> Date : 2006-4-20 >> >> This document describes modifications to DNS procedures used to >> resolve a SIP Uniform Resource Identifier (URI) into the >IP address, >> port, and transport protocol of the next hop to contact. These >> modifications enable the SIP User Agent to discover those proxies, >> within the domain of the SIP URI, that support SIP extensions >> described in draft-ietf-sip-outbound document. The introduced >> mechanisms update behavior defined in RFC 3263. >> >> >> A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun >d-discove >> ry-00.txt >> >> I would appreciate for anyone interested to review this spec >> and provide me with comments. >> >> Regards, >> >> Erkki >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 02 14:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazgc-0001P8-AN; Tue, 02 May 2006 14:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazga-0001Ms-FA for sip@ietf.org; Tue, 02 May 2006 14:33:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazgY-0000Nq-Ud for sip@ietf.org; Tue, 02 May 2006 14:33:24 -0400 Received: from [64.102.208.97] (dhcp-64-102-208-97.cisco.com [64.102.208.97]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k42IYJ4U011907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 2 May 2006 13:34:20 -0500 In-Reply-To: <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Tue, 2 May 2006 13:33:19 -0500 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c 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 text records are almost universally supported, as they're quire easy to add in a bind config file. However, most hosting-company front ends do not allow one to add them. For example, Network Solutions Inc. doesn't let one add TXT, SRZ, PTR, NAPTR, or anything else -- just A records, MX records, and CNAME records. As far as conventions for actually USING the content of text records being widely deployed, well, that's a new one on me. Said in Texan: "I ain't never seen nothing like that before, nosiree!" -- Dean On May 2, 2006, at 12:51 PM, Jeroen van Bemmel wrote: > Hi Erkki, > > Indeed, the extend of support for TEXT records or DNS-SD remains to > be determined also for me. Apparently the IETF once had a > workinggroup for this (http://www.zeroconf.org/) but apparently > they felt that their work was finished several years ago. > > I think we all agree that "a DNS-based solution" is required/ > acceptable. Now all that remains is to work out the details. > > Perhaps someone could do a quick test on a current DNS server, to > see how difficult it is to add a TEXT record, and what a client > would get? > > Regards, > > Jeroen > > > ----- Original Message ----- From: > To: ; > Sent: Tuesday, May 02, 2006 12:45 PM > Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound- > discovery-00.txt > > > > Hi Jeroen, > > I am sorry that I have not been able to respond your suggestions > before. I have been rather busy with my other assignment recently > (and will continue so probably in next 1-2 weeks). > > I hope to be able to study your proposals within 2-3 weeks and > tell if I find them feasible (or more feasible than those mechanisms > that my I-D currently uses). This far you are only person who has > expressed a strong concern about the DNS NAPTR record scalability > while some others have been happy with the solution I proposed. > So I would be grateful of the others to tell if they have similar > worries, in order to estimate which way would be the best to go. > > What comes to the TXT records, I do not have any information about > how widely they are currently supported. 15 years ago they were > not, according to RFC 1123 that says: > > The TXT and WKS RR types have not been widely used by > Internet sites; as a result, an application cannot > rely > on the the existence of a TXT or WKS RR in most > domains. > > Is this already obsolete ? Do everyone agree that TXT records could > now safely be used for the SIP Outbound discovery solution ? > > Regards, > > Erkki > >> -----Original Message----- >> From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 22.April.2006 12:02 >> To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org >> Subject: Re: [Sip] I-D >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >> >> Erkki, >> >> Another possibility: http://www.dns-sd.org/ServiceTypes.html lists >> the >> following TXT keys defined for the "sip" service (amongst others): >> >> sip Session Initiation Protocol, signalling >> protocol for VoIP >> registrar SIP registrar (see RFC3261) >> proxy SIP proxy (see RFC3261) >> natproxy SIP proxy for NATed clients >> outproxy outbound SIP proxy (see RFC3261) >> stunserver STUN server DNS name or IP address >> [Further TXT record keys may be added in the future.] >> >> We could define a new TXT record key, say "outbound", and >> return that along >> with the result of a SRV lookup. In other words: use DNS-SD >> (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for >> the purpose >> of outbound proxy discovery >> >> Regards, >> >> jeroen >> >> ----- Original Message ----- From: "Jeroen van Bemmel" >> >> To: ; >> Sent: Friday, April 21, 2006 7:43 PM >> Subject: Re: [Sip] I-D >> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >> >> >>> Erkki, >>> >>> To me the draft too easily discards the "this is not >> scalable" argument. >>> It really is not scalable, and stacking features on DNS like >> this feels >>> wrong. >>> >>> RFC2915 hints at an alternative approach in the description >> of the usage >>> of the "U" flag: "[...] there may be applications that use >> NAPTR to also >>> lookup aspects of URIs". You could use a regular expression >> including a >>> flag that denotes outbound support. >>> >>> Regards, >>> >>> Jeroen >>> >>> ----- Original Message ----- From: >>> To: >>> Sent: Friday, April 21, 2006 1:34 PM >>> Subject: RE: [Sip] I-D >>> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt >>> >>> >>> Hi, >>> >>>> I made up two proposals based on DNS for the UA to find >>>> out proxies supporting outbound within the domain of SIP >>>> AOR of the user or the domain got from DHCP ... >>>> >>>> I am now planning to put together an I-D for those proposals >>>> as an update to RFC 3263. It may take some time, but hopefully >>>> not too long. >>> >>> The promised I-D is now available: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Discovering Proxies Supporting SIP Outbound >>> Author(s) : E. Koivusalo >>> Filename : draft-koivusalo-sip-outbound-discovery-00.txt >>> Pages : 17 >>> Date : 2006-4-20 >>> >>> This document describes modifications to DNS procedures used to >>> resolve a SIP Uniform Resource Identifier (URI) into the >> IP address, >>> port, and transport protocol of the next hop to contact. These >>> modifications enable the SIP User Agent to discover those proxies, >>> within the domain of the SIP URI, that support SIP extensions >>> described in draft-ietf-sip-outbound document. The introduced >>> mechanisms update behavior defined in RFC 3263. >>> >>> >>> A URL for this Internet-Draft is: >>> >> http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun >> d-discove >>> ry-00.txt >>> >>> I would appreciate for anyone interested to review this spec >>> and provide me with comments. >>> >>> Regards, >>> >>> Erkki >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 02 15:59:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0zM-0000Ki-Qo; Tue, 02 May 2006 15:56:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0zL-0000KW-4g for sip@ietf.org; Tue, 02 May 2006 15:56:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0zJ-0004tM-RG for sip@ietf.org; Tue, 02 May 2006 15:56:51 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 12:56:49 -0700 X-IronPort-AV: i="4.05,80,1146466800"; d="scan'208"; a="1800649104:sNHT30511872" 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 k42JumVI002605; Tue, 2 May 2006 12:56:48 -0700 (PDT) Received: from [171.71.193.207] (dhcp-171-71-193-207.cisco.com [171.71.193.207]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k42JtEgs001045; Tue, 2 May 2006 12:55:14 -0700 Message-ID: <4457B985.5020603@cisco.com> Date: Tue, 02 May 2006 12:56:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1167; t=1146599714; x=1147463714; c=relaxed/simple; s=oregon; h=To: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]=20I-D=20ACTION=3Adraft-koivusalo-sip-outbound-discovery-00 .txt |To:Dean=20Willis=20; X=v=3Dcisco.com=3B=20h=3D4u0hr4KLPXko0KJXcnrbzlfTN9w=3D; b=bSe2gSIcJ2nsCOuCVHBVgjabDpC9miJtMNlTHQAwAcrOZpN9VqMbRGn9VCQ2hJNBJwFM59jm 5OaHEXIWsOvymIQavwezcCxWo8lq50ypO0Q1WYdTx5wcOzn2Nv/sVuDN; Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 Dean Willis wrote: > > > text records are almost universally supported, as they're quire easy > to add in a bind config file. > > > However, most hosting-company front ends do not allow one to add > them. For example, Network Solutions Inc. doesn't let one add TXT, > SRZ, PTR, NAPTR, or anything else -- just A records, MX records, and > CNAME records. As far as I've seen, the use of TXT records doesn't seem to be a source of major hardship for either SPF or DKIM. I'm certain that Dean is right about these providers, but there is some pressure on them given the above. > > As far as conventions for actually USING the content of text records > being widely deployed, well, that's a new one on me. Lots of people use them right now with SPF/SID and DK/DKIM. A word of caution: use of TXT records will get you an earful from the IAB. The entire area is a huge tangle and you need to be extremely cautious about how you use TXT records. Like for example, do not put them at the top of the domain, knowing what your expectations are for wildcarding (DNS wildcards do not work the way you would hope), etc. 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 May 02 16:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Nm-0005f4-TA; Tue, 02 May 2006 16:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1Nl-0005ez-RL for sip@ietf.org; Tue, 02 May 2006 16:22:05 -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 1Fb1Nl-0005v5-JC for sip@ietf.org; Tue, 02 May 2006 16:22:05 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYN00D01N9LTX@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:22:33 +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 <0IYN0099ZN9KHR@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:22:32 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 02 May 2006 21:22:04 +0100 Content-return: allowed Date: Tue, 02 May 2006 21:22:03 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708CFA25E@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: d6b246023072368de71562c0ab503126 Subject: [Sip] Issue 3 in draft-ietf-sip-connected-identity-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 The third issue is in section 6.5 as follows: "OPEN ISSUE. draft-ietf-sip-identity is silent on how to behave if the identity in the From header is not one that authenticated UA is allowed to assert. Should the request be allowed to proceed without the Identity header or should it be rejected, if so with which response code?" The sip-identity draft really leaves it to local policy, and I think that has to be the case for connected identity too. An Authentication Service could apply different policy for a mid-dialog request compared with an initial request (e.g., forward the request without adding the Identity header), but basically I think the draft should leave it to policy. Any opinions? 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 Tue May 02 16:23:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1NM-0005TV-3r; Tue, 02 May 2006 16:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1NK-0005Sr-05 for sip@ietf.org; Tue, 02 May 2006 16:21:38 -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 1Fb1NJ-0005uA-Nf for sip@ietf.org; Tue, 02 May 2006 16:21:37 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYN00D01N8MKB@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:21:58 +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 <0IYN0099CN8MHR@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:21:58 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 02 May 2006 21:21:30 +0100 Content-return: allowed Date: Tue, 02 May 2006 21:21:29 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708CFA25D@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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Issue 2 in draft-ietf-sip-connected-identity-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 The second issue concerns the fact that an UPDATE request in the backward direction following dialog establishment can be wasted if the peer UA (the UAC for the INVITE transaction) does not support it. It states: "OPEN ISSUE: If the identity has has not changed compared with the URI in the To header field and the UAC (for the INVITE request) does not support verification of an Identity header, this UPDATE or re-INVITE transaction would fulfil no useful purpose. However, the UAS (for the INVITE transaction) does not know this. In order to save this round trip, should we have an additional option tag to indicate support for receipt of the Identity header on mid- dialog requests? Then if this option tag is not present in the INVITE request the additional transaction could be omitted. Note that the id-change option tag does not seem appropriate for this purpose, since a UA could support a change of URI without supporting Identity." Whilst I do not wish to proliferate option tags, I do see some benefit in such a tag. Any opinions? 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 Tue May 02 16:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1PC-00074B-GL; Tue, 02 May 2006 16:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1PA-000741-MW for sip@ietf.org; Tue, 02 May 2006 16:23:32 -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 1Fb1PA-00060m-Ef for sip@ietf.org; Tue, 02 May 2006 16:23:32 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYN00E01NBZ0F@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:24:00 +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 <0IYN009AXNBZHR@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:23:59 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 02 May 2006 21:23:31 +0100 Content-return: allowed Date: Tue, 02 May 2006 21:23:30 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708CFA25F@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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] Issue 4 in draft-ietf-sip-connected-identity-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 The fourth issue is not actually in draft-00 but was raised subsequently. If a UA supports a change of From header field URI mid-dialog, as indicated by the "id-change" option tag, we could mandate that it also support the SIP UPDATE method. Then the peer UA in a dialog would be free to use the UPDATE method to report connected identity, rather than the less suitable re-INVITE method. The use of UPDATE means 2 messages instead of 3 and avoids the need for an offer-answer exchange. I heard no objections when this was proposed a few days ago. Do we have consensus? 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 Tue May 02 17:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2gH-0004Ly-48; Tue, 02 May 2006 17:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb2gF-0004Lo-9t for sip@ietf.org; Tue, 02 May 2006 17:45:15 -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 1Fb1QW-00065V-7G for sip@ietf.org; Tue, 02 May 2006 16:24:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fb1La-0005T0-Rt for sip@ietf.org; Tue, 02 May 2006 16:19:54 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYN00D01N5RA1@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:20: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 <0IYN00982N5RHR@siemenscomms.co.uk> for sip@ietf.org; Tue, 02 May 2006 21:20:15 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 02 May 2006 21:19:47 +0100 Content-return: allowed Date: Tue, 02 May 2006 21:19:46 +0100 From: "Elwell, John" To: sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708CFA25B@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: -2.6 (--) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Sip] Issue 1 in draft-ietf-sip-connected-identity-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 There are three open issues in this draft and a fourth that was raised subsequently. This mail initiates discussion on the first issue. I will initiate discussion on the other three issues in separate mails. Issue 1 appears in section 5 and concerns the fact that this draft intentionally does not address response identity, and therefore the identity of a dialog-forming responder to an INVITE request is conveyed in a separate request (e.g., UPDATE) in the reverse direction rather than in the response to the INVITE request. The open issue is stated as: "OPEN ISSUE. Should this be extended to allow a URI in the To header field of a response to change compared with the To header field in a request? This could convey a connected identity in a response to an INVITE request, but it would not be authenticated. Authentication would have to rely on transitive trust, which might be feasible in a closed environment where the sips URI scheme is used." There was considerable list discussion on this shortly after IETF65 with no resolution. I won't attempt to summarise it. My opinion (for what it's worth) is as follows. 1. Whereas RFC 3261 anticipates deprecating fixed To/From header field URIs throughout a dialog (i.e., it anticipates that these will be allowed to change mid-dialog), it says nothing to warn of any future removal of the requirement that the To header field URI in the response be the same as that in the request. Therefore I believe it would be dangerous to specify such a change to the To header field URI. 2. The prime motivation for this draft was to provide authenticated identity, i.e., to complement the sip-identity draft. An identity in the To header field of a response cannot be authenticated, for reasons stated many times on this list and at meetings. Therefore, at least in the Internet, a response identity would have little value. 3. A comprehensive list of reasons for not going down that path were given by Jon Peterson (editor of the Identity draft) in a message to this list on 5th April. 4. In closed environments an unauthenticated response identity might have some value. But this could be achieved using P-Asserted-Identity, say, rather than bending the rules for To headers in responses. Therefore I am NOT in favour of enhancing the draft to provide identity in the To header field URI of a response. Can people agree to this resolution of the issue? John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 26 April 2006 20:50 > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol > Working Group of the IETF. > > Title : Connected Identity in the Session > Initiation Protocol (SIP) > Author(s) : J. Elwell > Filename : draft-ietf-sip-connected-identity-00.txt > Pages : 20 > Date : 2006-4-26 > > Because of retargeting of a Session Initiation Protocol > (SIP) dialog- > forming request, the UAS can have a different identity from that in > the To header. This document provides a means for that 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 PSTN > behind a gateway. This document normatively updates RFC > 3261 (SIP). > This work is being discussed on the sip@ietf.org mailing list. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > dentity-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-connected-identity-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-connected-identity-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 May 02 18:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3XI-0008ME-BE; Tue, 02 May 2006 18:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3XG-0008Fr-7s for sip@ietf.org; Tue, 02 May 2006 18:40:02 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3XE-0004XV-J9 for sip@ietf.org; Tue, 02 May 2006 18:40:02 -0400 Received: (qmail 7344 invoked by uid 0); 2 May 2006 22:39:56 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 May 2006 22:39:56 -0000 Message-ID: <006101c66e39$5790b390$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 3 May 2006 00:39:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 Erkki, > Perhaps someone could do a quick test on a current DNS server, to see how > difficult it is to add a TEXT record, and what a client would get? I just picked up the latest version of BIND for Windows (http://www.isc.org/index.pl?/sw/bind/), browsed around for configuration options, and managed to get the following (see appendix) Here I included several options to signal outbound support (in the zone config file, showing only UDP here): 1 - TXT outbound ; appears in example.com domain 2 - @ IN NAPTR 120 10 "u" "SIP+E2U" "!^.*$!sip:example.com;outbound" . 3 - @ IN NAPTR 110 50 "s" "SIP+D2U" "" _sipo._udp.example.com. 4 - @ IN NAPTR 110 50 "s" "SIP+D2U" "" _ob._sip._udp.example.com. 5 - @ IN NAPTR 150 50 "s" "SIP-O+D2U" "" _sip._udp.example.com. 6 - _outbound IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. I briefly considered a seventh option - adding an 'o' to the flags - but discarded that as inappropriate Interestingly, for NAPTR queries Bind also returns the corresponding SRV records in 'additional' records. This means that one query gives both. You could probably tweak a DNS server to output TXT records when a NAPTR query is performed, but this won't happen out of the box. A query for 'ANY' type of record also returns both, but drawback is then that the answer becomes large (with many irrelevant entries, and switching to TCP) You could use ENUM-style rewrite rules to indicate support for outbound (2). However, this would require a second lookup (unless the IP address + port were used in the rewrite expression, which has other drawbacks). Moreover, it is unclear how the client should proceed after the first lookup. That leaves us with (3)-(6), (5) being described in the draft currently. The _underscore syntax are really only conventions for DNS names, RFC3263 defines "_sip" and "_sips", RFC2782 (SRV) defines "_udp" and "_tcp". "_sipo" (and "_sipso") or "_ob._sip(s)" would fit in with the RFC3263 lookup process as follows: 1) Select transport based on NAPTR service fields with values "SIP+D2X" and "SIPS+D2X" 2) Determine Port and IP (for those proxies supporting outbound) Furthermore, this will also work for domains that do not use NAPTR: the convention of RFC3263 to use "_sip" and "_sips" for SRV lookup would be extended with "_sipo" and "_sipso", or "_ob._sip(s)" . The number of NAPTR records would however still double, and also additional SRV records are needed here Finally, the last option is perhaps the simplest one: adopt the convention to prepend "_outbound." to the domain name, and do a NAPTR lookup on that. This basically puts outbound selection before transport selection, so the process in RFC3263 would become: 0) Determine if you want / need outbound 1) Select transport 2) Determine IP + port No additional SRVs needed here, and this does not change transport selection (while "SIP-O+D2U" does). When the domain does not support outbound, a second lookup is needed (without _outbound) but you might be able to combine those 2 queries in 1 DNS NAPTR request Regards, jeroen Appendix: dig output --------------------- C:\WINDOWS\SYSTEM32\dns\bin>dig -t NAPTR example.com ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.2 <<>> -t NAPTR example.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1704 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 1, ADDITIONAL: 8 ;; QUESTION SECTION: ;example.com. IN NAPTR ;; ANSWER SECTION: example.com. 3600 IN NAPTR 150 50 "s" "SIP-O+D2U" "" _sip._udp.example.com. example.com. 3600 IN NAPTR 160 50 "s" "SIP-O+D2T" "" _sip._tcp.example.com. example.com. 3600 IN NAPTR 170 50 "s" "SIPS-O+D2T" "" _sips._tcp.example.com. example.com. 3600 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. example.com. 3600 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com. example.com. 3600 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. example.com. 3600 IN NAPTR 110 50 "s" "SIP+D2U" "" _sipo._udp.example.com. example.com. 3600 IN NAPTR 111 50 "s" "SIP+D2T" "" _sipo._tcp.example.com. example.com. 3600 IN NAPTR 111 50 "s" "SIP+D2U" "" _ob._sip._udp.example.com. example.com. 3600 IN NAPTR 120 10 "u" "SIP+E2U" "!^.*$!sip:example.com\;outbound" . ;; AUTHORITY SECTION: example.com. 3600 IN NS host.example.com. ;; ADDITIONAL SECTION: sipx.example.com. 3600 IN A 127.0.0.1 outbound.sip.example.com. 3600 IN A 127.0.0.1 _sips._tcp.example.com. 3600 IN SRV 300 1 5061 sipx.example.com. _sip._tcp.example.com. 3600 IN SRV 200 1 5060 sipx.example.com. _sip._udp.example.com. 3600 IN SRV 100 1 5060 sipx.example.com. _sipo._udp.example.com. 3600 IN SRV 100 1 5060 sipx.example.com. _sipo._tcp.example.com. 3600 IN SRV 200 1 5060 sipx.example.com. _ob._sip._udp.example.com. 3600 IN SRV 120 1 5060 outbound.sip.example.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 03 00:14:57 2006 ;; MSG SIZE rcvd: 846 C:\WINDOWS\SYSTEM32\dns\bin>dig -t ANY example.com ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.2 <<>> -t ANY example.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1004 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 8 ;; QUESTION SECTION: ;example.com. IN ANY ;; ANSWER SECTION: example.com. 3600 IN NAPTR 111 50 "s" "SIP+D2U" "" _ob._sip._udp.example.com. example.com. 3600 IN NAPTR 120 10 "u" "SIP+E2U" "!^.*$!sip:example.com\;outbound" . example.com. 3600 IN NAPTR 150 50 "s" "SIP-O+D2U" "" _sip._udp.example.com. example.com. 3600 IN NAPTR 160 50 "s" "SIP-O+D2T" "" _sip._tcp.example.com. example.com. 3600 IN NAPTR 170 50 "s" "SIPS-O+D2T" "" _sips._tcp.example.com. example.com. 3600 IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. example.com. 3600 IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com. example.com. 3600 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. example.com. 3600 IN NAPTR 110 50 "s" "SIP+D2U" "" _sipo._udp.example.com. example.com. 3600 IN NAPTR 111 50 "s" "SIP+D2T" "" _sipo._tcp.example.com. example.com. 3600 IN TXT "outbound" example.com. 3600 IN SOA host.example.com. unused-email.example.com. 1 10800 3600 6048 example.com. 3600 IN NS host.example.com. ;; ADDITIONAL SECTION: sipx.example.com. 3600 IN A 127.0.0.1 outbound.sip.example.com. 3600 IN A 127.0.0.1 _sips._tcp.example.com. 3600 IN SRV 300 1 5061 sipx.example.com. _sip._tcp.example.com. 3600 IN SRV 200 1 5060 sipx.example.com. _sip._udp.example.com. 3600 IN SRV 100 1 5060 sipx.example.com. _sipo._udp.example.com. 3600 IN SRV 100 1 5060 sipx.example.com. _sipo._tcp.example.com. 3600 IN SRV 200 1 5060 sipx.example.com. _ob._sip._udp.example.com. 3600 IN SRV 120 1 5060 outbound.sip.example.com. ;; Query time: 15 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 03 00:15:07 2006 ;; MSG SIZE rcvd: 916 C:\WINDOWS\SYSTEM32\dns\bin>dig -t NAPTR _outbound.example.com ; <<>> DiG 9.3.2 <<>> -t NAPTR _outbound.example.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 984 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: ;_outbound.example.com. IN NAPTR ;; ANSWER SECTION: _outbound.example.com. 3600 IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. ;; AUTHORITY SECTION: example.com. 3600 IN NS host.example.com. ;; ADDITIONAL SECTION: sipx.example.com. 3600 IN A 127.0.0.1 _sip._udp.example.com. 3600 IN SRV 100 1 5060 sipx.example.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 03 00:28:01 2006 ;; MSG SIZE rcvd: 165 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 03 02:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbAwG-0001Ag-JR; Wed, 03 May 2006 02:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbAwF-00019W-1i for sip@ietf.org; Wed, 03 May 2006 02:34:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbAwE-0006ia-V6 for sip@ietf.org; Wed, 03 May 2006 02:34:19 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbAwE-0001J5-9i for sip@ietf.org; Wed, 03 May 2006 02:34:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k436Y8M7029431; Wed, 3 May 2006 09:34:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 09:33:32 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 09:33:30 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 3 May 2006 09:33:29 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> In-Reply-To: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZq4g4yVKovHyl0SlmIFaIJ9H0bwwAAXp+QAOWPQIA= From: To: , X-OriginalArrivalTime: 03 May 2006 06:33:30.0985 (UTC) FILETIME=[7E8D2590:01C66E7B] X-Spam-Score: -2.4 (--) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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, >> operator wants to have load balancing, there must be at least two >> primaries and perhaps also two backups organized in such a=20 >> way that if one primary goes down. also the other needs to be brought >> down, because otherwise there would be no load balancing. I do not think the sizes of the primary and proxy farms should necessarily be the same. Instead of applying 1+1 protection you can also arrange 1:N protection e.g. by having the SRV record of primary proxies to resolve as 2 servers and the SRV record of backup proxies to resolve as 1 single server. Each of the two primary proxies would serve half of the UA population while the single backup one could take over the load of any of the primaries failing. Load balancing would be kept as only those UAs using the failed proxy as their primary would now start to use the backup server. >> if all proxies are the same, then operaor can add a new one=20 >> to the set and it automatically receives also some of the load. Now the issue is whether the autodiscovery mechanism should support having redundant (idle) backup proxies or not. It=20 could also be possible to revise the I-D so that both ways would be possible. The mechanism would work e.g. like this: - If operator wants to use idle backup servers, a separate SRV record with higher Priority value could be introduced for those (like the I-D currently proposes). - If the operator wants to use a single set of servers both for load balancing and backup, then only single SRV record would be introduced. In this case the UA should set up its primary and backup connection towards two different proxies within this single record. UA would only do so if it does not find SRV records for SIP Outbound with higher Priority value. Comments ? Regards, Erkki >-----Original Message----- >From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 >Sent: 28.April.2006 20:12 >To: 'Juha Heinanen' >Cc: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org >Subject: RE: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >But I think no matter what it will be the UA which decides=20 >which one to use >for active signaling. Even if you call them both primaries,=20 >the UAs would >probably just use the first one configured/discovered/bound=20 >for signaling. >If you specify they must choose it randomly then you could=20 >just say that >about the primary and backup terms. (although I agree the=20 >terms would be >highly confusing, as they already are for me) > >In some ways that's already going to happen - the draft does=20 >not say the UA >must use the "primary" for new outbound requests, and the=20 >registrar has no >idea which one the primary is, so new requests going to the UA will be >pseudo-randomly chosen. (if anything, it would probably use the most >recently bound one, which ironically means the backup will be the first >used) > >-hadriel > >> -----Original Message----- >> From: Juha Heinanen [mailto:jh@tutpro.com] >> Sent: Friday, April 28, 2006 12:37 PM >> To: Hadriel Kaplan >> Cc: Erkki.Koivusalo@nokia.com; sip@ietf.org >> Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery- >> 00.txt >>=20 >> Hadriel Kaplan writes: >>=20 >> > BTW, why does the terminology mistake make you need four proxies? >>=20 >> if one is primary and one is backup, then ua would always=20 >use primary as >> long as it is alive, i.e., backup would be on hot standby. so if >> operator wants to have load balancing, there must be at least two >> primaries and perhaps also two backups organized in such a=20 >way that if >> one primary goes down. also the other needs to be brought=20 >down, because >> otherwise there would be no load balancing. >>=20 >> if all proxies are the same, then operaor can add a new one=20 >to the set >> and it automatically receives also some of the load. >>=20 >> -- 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 Wed May 03 02:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbB7I-0006CY-Ro; Wed, 03 May 2006 02:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbB7H-0006CT-9p for sip@ietf.org; Wed, 03 May 2006 02:45:43 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbB7F-00071H-R6 for sip@ietf.org; Wed, 03 May 2006 02:45:43 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k436jckM004329; Wed, 3 May 2006 09:45:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 09:45:37 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 09:45:37 +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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 3 May 2006 09:45:24 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0243FC2C@esebe103.NOE.Nokia.com> In-Reply-To: <055e01c66df2$c90be130$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZt8vQfzIxYQ4v+Q/208wn8URVPBwAiJPOA From: To: , , X-OriginalArrivalTime: 03 May 2006 06:45:37.0011 (UTC) FILETIME=[2F4BEC30:01C66E7D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 am sorry gentlemen, but I am not able to understand the comment you are given. My I-D specifies how the UA should automatically (without any extra confguration information) find a primary and a backup proxy supporting SIP Outbound. For this purpose there should be some pretermined rules like: - Load balancing done as already specified in RFC 2782 (SRV RR). Using those well estabilished rules different UAs will already distribute their loads amongst multiple (primary) servers. =20 - Primary and Backup proxies found based on the Priority field of SRV RR So could you please explain what was your concern, e.g. by referring those statements in my earlier email that you found to impose unnecessary restrictions and what is the specific problem in those ? Regards, Erkki=20 >-----Original Message----- >From: ext Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 >Sent: 02.May.2006 17:15 >To: sip@ietf.org >Subject: Re: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 > >Definitely agree with Mike here. > >Spencer > >From: "Michael Hammer (mhammer)" >To: ; ;=20 > >Sent: Tuesday, May 02, 2006 8:50 AM >Subject: RE: [Sip] I-D=20 >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > >Hi. > >What one UA uses as primary or backup proxies versus another UA should >be totally independent and a matter of configuration. Don't build in >unnecessary restrictions that just cause trouble down the road. > >Mike=20 > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 03 06:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEB9-0006hd-DX; Wed, 03 May 2006 06:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEB8-0006hM-G9 for sip@ietf.org; Wed, 03 May 2006 06:01:54 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbEB7-0007ih-1O for sip@ietf.org; Wed, 03 May 2006 06:01:54 -0400 Received: (qmail 25057 invoked by uid 0); 3 May 2006 10:01:49 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 3 May 2006 10:01:49 -0000 Message-ID: <001801c66e98$98b8a580$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com><002d01c66e11$06fc5f60$31713b51@BEMBUSTER> <006101c66e39$5790b390$31713b51@BEMBUSTER> Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 3 May 2006 12:01:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 > Here I included several options to signal outbound support (in the zone > config file, showing only UDP here): > 1 - TXT outbound ; appears in example.com domain > 2 - @ IN NAPTR 120 10 "u" "SIP+E2U" "!^.*$!sip:example.com;outbound" . > 3 - @ IN NAPTR 110 50 "s" "SIP+D2U" "" _sipo._udp.example.com. > 4 - @ IN NAPTR 110 50 "s" "SIP+D2U" "" _ob._sip._udp.example.com. > 5 - @ IN NAPTR 150 50 "s" "SIP-O+D2U" "" _sip._udp.example.com. > 6 - _outbound IN NAPTR 100 50 "s" "SIP+D2U" "" > _sip._udp.example.com. > > I briefly considered a seventh option - adding an 'o' to the flags - but > discarded that as inappropriate I also found RFC3958 (http://www.ietf.org/rfc/rfc3958.txt) which provides another alternative, but at a higher level. In retrospect, if RFC3263 would have followed RFC3958, we might have had @ IN NAPTR 150 50 "s" "VoIP:sipOu" "" _sip._udp.example.com. The "+D2U" syntax refers to a resolution service according to RFC2915 (like E2U for ENUM and I2L, I2C, ... for URI resolution, see http://rfc.net/rfc2483.html), apparently it means "Domain to UDP" which seems odd. OTOH, the case for protocols with multiple transports seems underspecified in RFC2915. Ah well, guess we'll have to live with it. Having explored all these options, I have personally come to the conclusion that there are 2 choices: A) "SIP-O+D2U" which is not that bad, given what we currently have. If we specify it in the draft as "SIP-O+X", where "X" is any SIP transport mapping (current or future), then this is a reasonable approach B) TXT outbound, associated with particular SRV records. The other alternatives are considered "name hacks" (RFC3958). To support case (B), we could use the flags field. RFC2915 says "DNS servers MAY interpret these flags and values and use that information to include appropriate SRV and A,AAAA, or A6 records in the additional information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so." (Section 2) Therefore, I propose to define a new "t" flag to mean that TXT records are to be included in response to the query. A client could then do a NAPTR query as is. It can then do a SRV query, and scan the additional records for outbound support. The TXT records should not be global for the domain, but specific to each SRV record (i.e. per server). All of this can be realized with a minor change to DNS server configuration (benefit: no duplication of NAPTR records) and the server itself (to interpret the "t" flag). Note that Bind will return both NAPTR records and SRV records in the first query, if TXT records are added then the client only needs 1 roundtrip. I feel (B) is more appropriate because outbound support is really a per-server property, not a per-domain property. Furthermore, once we have this it can also be used for other (future) features one might want to discover about servers. Do we need to specify anything for SRV-only clients? If so, I think the draft should recommend that domains define "_ob._sip._udp.example.com" SRV records, such that the RFC3263 case of "no NAPTR records" can be supported. 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 May 03 09:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGwf-0004ln-Fp; Wed, 03 May 2006 08:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGwd-0004li-83 for sip@ietf.org; Wed, 03 May 2006 08:59:07 -0400 Received: from pproxy.gmail.com ([64.233.166.178] helo=py-out-1112.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbGwc-0006uW-1Y for sip@ietf.org; Wed, 03 May 2006 08:59:07 -0400 Received: by py-out-1112.google.com with SMTP id e30so199287pya for ; Wed, 03 May 2006 05:59:05 -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=ZgezNIQzYx5gIvwP/dFfg7uDO+68hMlpFi8DB569pghkJbvkM89+RbVnmSlEt0qnYoFD6yY6N4BCUiZObWIid/pO2oD38dBrDN2lUx/IavWtL18C8hgbBSaY+IoaXsdSCexh3YrNXfLGoGdbEJtApnjWpDYicr8TKG8K3sUoxlw= Received: by 10.35.81.10 with SMTP id i10mr1161962pyl; Wed, 03 May 2006 05:59:00 -0700 (PDT) Received: by 10.35.54.16 with HTTP; Wed, 3 May 2006 05:59:00 -0700 (PDT) Message-ID: <52db68bc0605030559j5aec2cfar381e82697f97a26f@mail.gmail.com> Date: Wed, 3 May 2006 18:29:00 +0530 From: Sudhir To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.4 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] query regarding BYE request-URI X-BeenThere: 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="===============1839321818==" Errors-To: sip-bounces@ietf.org --===============1839321818== Content-Type: multipart/alternative; boundary="----=_Part_12267_17041302.1146661140671" ------=_Part_12267_17041302.1146661140671 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, If UA received INVITE request with contact and record-route header, when UA want to built the BYE request. How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI? Any response is appreciated Thanks in advance Sudhir ------=_Part_12267_17041302.1146661140671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi All,

If UA received INVITE request with contact and record-route header, when= UA want to built the BYE request.

How BYE request-URI is built? Should I use either record-route or contac= t header to construct BYE request-URI?


Any response is appreciated

Thanks in advance
Sudhir

 

------=_Part_12267_17041302.1146661140671-- --===============1839321818== 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 --===============1839321818==-- From sip-bounces@ietf.org Wed May 03 12:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKC7-0006Cs-9w; Wed, 03 May 2006 12:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbKC5-0006Cm-GT for sip@ietf.org; Wed, 03 May 2006 12:27:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbIYN-00033D-Lp for sip@ietf.org; Wed, 03 May 2006 10:42:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbHxU-0005SH-BK for sip@ietf.org; Wed, 03 May 2006 10:04:06 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 May 2006 10:04:04 -0400 X-IronPort-AV: i="4.05,84,1146456000"; d="scan'208"; a="87789140:sNHT32698916" 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 k43E43vF024456; Wed, 3 May 2006 10:04:03 -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.211); Wed, 3 May 2006 10:04:03 -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] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Date: Wed, 3 May 2006 10:04:02 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301698A9E@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt Thread-Index: AcZt8vQfzIxYQ4v+Q/208wn8URVPBwAiJPOAAA8nm9A= From: "Michael Hammer \(mhammer\)" To: , , X-OriginalArrivalTime: 03 May 2006 14:04:03.0632 (UTC) FILETIME=[6F43BB00:01C66EBA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Erkki, In general, I didn't have a problem with how you were describing the use of the priority mechanisms to select proxies from one or more pools of proxies, such that one could do both load balancing within a farm and be able to designate primary and backup sets of proxies. But, somewhere in the process you seemed to have crossed over from defining the options into selecting an option and ruling out other options. I tried to go back to the email and pull out the text that raised the red flag for me: "And now the real problem (which is actually an issue within draft-ietf-sip-outbound-03) is: if a single UA still needs a backup=20 proxy (and a backup connection), shall those backup proxies be one of=20 those the other UAs are using as their primaries or should those=20 backup proxies be totally separate from the primary proxy farm ?=20 Currently draft-ietf-sip-outbound-03 seems to suggest having separate set of=20 primary proxies and another set of backup proxies: The deployment here requires that DNS is configured with one entry that resolves to all the primary hosts and another entry that resolves to all the backup hosts. Designs having only one set were also considered, but in=20 this case there would have to be some way to ensure that the two connection did not accidentally resolve to the same host.=20 If the agreement will be that no dedicated backup proxies should be=20 used for SIP Outbound but instead one common set of proxies should be=20 used both for load balancing and backup purposes then I would suggest: " Note that the tone of this last sentence seemed to start ruling out options. Describing the options and their pros and cons is good. Stating that a particular option is the preferred approach is good. But, unless there is an interoperability problem, the service provider should be allowed to control how he deploys his proxies. If you read it in that light, you can avoid what might be an arbitrary restriction. Mike > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: Wednesday, May 03, 2006 2:45 AM > To: spencer@mcsr-labs.org; sip@ietf.org; Michael Hammer (mhammer) > Subject: RE: [Sip] I-D=20 > ACTION:draft-koivusalo-sip-outbound-discovery-00.txt=20 >=20 > Hi, >=20 > I am sorry gentlemen, but I am not able to understand the=20 > comment you are given. My I-D specifies how the UA should=20 > automatically (without any extra confguration information)=20 > find a primary and a backup proxy supporting SIP Outbound.=20 > For this purpose there should be some pretermined rules like: >=20 > - Load balancing done as already specified in RFC 2782 (SRV RR). > Using those well estabilished rules different UAs will already > distribute their loads amongst multiple (primary) servers. > =20 > - Primary and Backup proxies found based on the Priority > field of SRV RR >=20 > So could you please explain what was your concern, e.g. > by referring those statements in my earlier email that you=20 > found to impose unnecessary restrictions and what is the=20 > specific problem in those ? >=20 > Regards, >=20 > Erkki=20 >=20 > >-----Original Message----- > >From: ext Spencer Dawkins [mailto:spencer@mcsr-labs.org] > >Sent: 02.May.2006 17:15 > >To: sip@ietf.org > >Subject: Re: [Sip] I-D > >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > >Definitely agree with Mike here. > > > >Spencer > > > >From: "Michael Hammer (mhammer)" > >To: ; ;=20 > > > >Sent: Tuesday, May 02, 2006 8:50 AM > >Subject: RE: [Sip] I-D > >ACTION:draft-koivusalo-sip-outbound-discovery-00.txt > > > > > >Hi. > > > >What one UA uses as primary or backup proxies versus another=20 > UA should=20 > >be totally independent and a matter of configuration. Don't=20 > build in=20 > >unnecessary restrictions that just cause trouble down the road. > > > >Mike > > > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 04 04:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZKX-0007s5-Pb; Thu, 04 May 2006 04:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZKX-0007s0-05 for sip@ietf.org; Thu, 04 May 2006 04:37:01 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZKV-0006a8-Eo for sip@ietf.org; Thu, 04 May 2006 04:37:00 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Thu, 4 May 2006 10:36:58 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 4 May 2006 10:36:57 +0200 Message-Id: <31529C1D0F94F24989CBC1BCDF3C04970818BE46@S4DE8PSAAGT.blf.telekom.de> From: "Jesske, R" To: john.elwell@siemens.com, sip@ietf.org Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Thu, 4 May 2006 10:36:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Dear John et all, I'm sorry to go again into the opposite oppinion but I'm still in = favour of enhancing the draft to provide identity in the To header = field URI of a response. I don't know if we have to rediscuss all the possibilities and = assumptions. But fact is that such a to header change would be useful = for some services. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Dienstag, 2. Mai 2006 22:20 > An: sip@ietf.org > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 >=20 > There are three open issues in this draft and a fourth that was = raised > subsequently. This mail initiates discussion on the first=20 > issue. I will > initiate discussion on the other three issues in separate mails. >=20 > Issue 1 appears in section 5 and concerns the fact that this draft > intentionally does not address response identity, and=20 > therefore the identity > of a dialog-forming responder to an INVITE request is=20 > conveyed in a separate > request (e.g., UPDATE) in the reverse direction rather than=20 > in the response > to the INVITE request. The open issue is stated as: >=20 > "OPEN ISSUE. Should this be extended to allow a URI in the To > header field of a response to change compared with the To = header > field in a request? This could convey a connected identity in = a > response to an INVITE request, but it would not be=20 > authenticated. > Authentication would have to rely on transitive trust,=20 > which might > be feasible in a closed environment where the sips URI scheme = is > used." >=20 > There was considerable list discussion on this shortly after=20 > IETF65 with no > resolution. I won't attempt to summarise it. My opinion (for what = it's > worth) is as follows. >=20 > 1. Whereas RFC 3261 anticipates deprecating fixed To/From=20 > header field URIs > throughout a dialog (i.e., it anticipates that these will be=20 > allowed to > change mid-dialog), it says nothing to warn of any future=20 > removal of the > requirement that the To header field URI in the response be=20 > the same as that > in the request. Therefore I believe it would be dangerous to=20 > specify such a > change to the To header field URI. >=20 > 2. The prime motivation for this draft was to provide authenticated > identity, i.e., to complement the sip-identity draft. An=20 > identity in the To > header field of a response cannot be authenticated, for=20 > reasons stated many > times on this list and at meetings. Therefore, at least in=20 > the Internet, a > response identity would have little value. >=20 > 3. A comprehensive list of reasons for not going down that=20 > path were given > by Jon Peterson (editor of the Identity draft) in a message=20 > to this list on > 5th April. >=20 > 4. In closed environments an unauthenticated response=20 > identity might have > some value. But this could be achieved using P-Asserted-Identity, = say, > rather than bending the rules for To headers in responses. >=20 > Therefore I am NOT in favour of enhancing the draft to=20 > provide identity in > the To header field URI of a response. Can people agree to=20 > this resolution > of the issue? >=20 > John >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > > Sent: 26 April 2006 20:50 > > To: i-d-announce@ietf.org > > Cc: sip@ietf.org > > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt > >=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 : Connected Identity in the Session=20 > > Initiation Protocol (SIP) > > Author(s) : J. Elwell > > Filename : draft-ietf-sip-connected-identity-00.txt > > Pages : 20 > > Date : 2006-4-26 > > =09 > > Because of retargeting of a Session Initiation Protocol=20 > > (SIP) dialog- > > forming request, the UAS can have a different identity=20 > from that in > > the To header. This document provides a means for that UA=20 > > 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 PSTN > > behind a gateway. This document normatively updates RFC=20 > > 3261 (SIP). > > This work is being discussed on the sip@ietf.org mailing list. > >=20 > >=20 > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > dentity-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 the message. =20 > > You can also visit=20 > > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > > to change your subscription settings. > >=20 > >=20 > > Internet-Drafts are also available by anonymous FTP. Login=20 > > 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-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 > >=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-connected-identity-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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > 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 sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 04 06:42:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbFu-0003lg-1k; Thu, 04 May 2006 06:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbFt-0003lb-8Y for sip@ietf.org; Thu, 04 May 2006 06:40:21 -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 1FbbFs-0004Bx-Mb for sip@ietf.org; Thu, 04 May 2006 06:40:21 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYQ00301LNHD3@siemenscomms.co.uk> for sip@ietf.org; Thu, 04 May 2006 11:40:29 +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 <0IYQ0028DLMMSH@siemenscomms.co.uk>; Thu, 04 May 2006 11:39:58 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Thu, 04 May 2006 11:39:30 +0100 Content-return: allowed Date: Thu, 04 May 2006 11:39:29 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Jesske, R" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D3DD55@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Roland, Well, you would need to convince the community that this is a = worthwhile and safe thing to do. Agreement to date is only to change From and To = header field URIs in mid-dialog requests. Changing the To header field URI in = a response would require separate agreement. I suggest you write an I-D = and try to get backing. However, I fear you will encounter strong = opposition. Regards, John=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 04 May 2006 09:37 > To: Elwell, John; sip@ietf.org > Cc: chister.holmberg@ericsson.com;=20 > sebastien.garcin@francetelecom.com; Alexeitsev, D; esasaki@NTT-AT.COM > Subject: AW: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 > Dear John et all, > I'm sorry to go again into the opposite oppinion but I'm=20 > still in favour of enhancing the draft to provide identity=20 > in the To header field URI of a response. >=20 > I don't know if we have to rediscuss all the possibilities=20 > and assumptions. But fact is that such a to header change=20 > would be useful for some services. >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > An: sip@ietf.org > > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > There are three open issues in this draft and a fourth that=20 > was raised > > subsequently. This mail initiates discussion on the first=20 > > issue. I will > > initiate discussion on the other three issues in separate mails. > >=20 > > Issue 1 appears in section 5 and concerns the fact that this draft > > intentionally does not address response identity, and=20 > > therefore the identity > > of a dialog-forming responder to an INVITE request is=20 > > conveyed in a separate > > request (e.g., UPDATE) in the reverse direction rather than=20 > > in the response > > to the INVITE request. The open issue is stated as: > >=20 > > "OPEN ISSUE. Should this be extended to allow a URI in the = To > > header field of a response to change compared with=20 > the To header > > field in a request? This could convey a connected=20 > identity in a > > response to an INVITE request, but it would not be=20 > > authenticated. > > Authentication would have to rely on transitive trust,=20 > > which might > > be feasible in a closed environment where the sips=20 > URI scheme is > > used." > >=20 > > There was considerable list discussion on this shortly after=20 > > IETF65 with no > > resolution. I won't attempt to summarise it. My opinion=20 > (for what it's > > worth) is as follows. > >=20 > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From=20 > > header field URIs > > throughout a dialog (i.e., it anticipates that these will be=20 > > allowed to > > change mid-dialog), it says nothing to warn of any future=20 > > removal of the > > requirement that the To header field URI in the response be=20 > > the same as that > > in the request. Therefore I believe it would be dangerous to=20 > > specify such a > > change to the To header field URI. > >=20 > > 2. The prime motivation for this draft was to provide authenticated > > identity, i.e., to complement the sip-identity draft. An=20 > > identity in the To > > header field of a response cannot be authenticated, for=20 > > reasons stated many > > times on this list and at meetings. Therefore, at least in=20 > > the Internet, a > > response identity would have little value. > >=20 > > 3. A comprehensive list of reasons for not going down that=20 > > path were given > > by Jon Peterson (editor of the Identity draft) in a message=20 > > to this list on > > 5th April. > >=20 > > 4. In closed environments an unauthenticated response=20 > > identity might have > > some value. But this could be achieved using=20 > P-Asserted-Identity, say, > > rather than bending the rules for To headers in responses. > >=20 > > Therefore I am NOT in favour of enhancing the draft to=20 > > provide identity in > > the To header field URI of a response. Can people agree to=20 > > this resolution > > of the issue? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > > > Sent: 26 April 2006 20:50 > > > To: i-d-announce@ietf.org > > > Cc: sip@ietf.org > > > Subject: [Sip] I-D = ACTION:draft-ietf-sip-connected-identity-00.txt > > >=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 : Connected Identity in the Session=20 > > > Initiation Protocol (SIP) > > > Author(s) : J. Elwell > > > Filename : draft-ietf-sip-connected-identity-00.txt > > > Pages : 20 > > > Date : 2006-4-26 > > > =09 > > > Because of retargeting of a Session Initiation Protocol=20 > > > (SIP) dialog- > > > forming request, the UAS can have a different identity=20 > > from that in > > > the To header. This document provides a means for that UA=20 > > > to supply > > > its identity to the peer UA by means of a request in=20 > the reverse > > > direction and for that identity to be signed by an=20 > Authentication > > > Service. The same mechanism can be used to indicate a=20 > change of > > > identity during a dialog, e.g., because of some action=20 > in a PSTN > > > behind a gateway. This document normatively updates RFC=20 > > > 3261 (SIP). > > > This work is being discussed on the sip@ietf.org mailing list. > > >=20 > > >=20 > > >=20 > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > dentity-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 the message. =20 > > > You can also visit=20 > > > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > > > to change your subscription settings. > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP. Login=20 > > > with the username > > > "anonymous" and a password of your e-mail address. After=20 > logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-sip-connected-identity-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 > > >=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-connected-identity-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. > > > =09 > > > =09 > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > 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 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 Thu May 04 07:10:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbhP-0007Dx-36; Thu, 04 May 2006 07:08:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbhN-0007Ds-8I for sip@ietf.org; Thu, 04 May 2006 07:08:45 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbbhD-0005WA-Ea for sip@ietf.org; Thu, 04 May 2006 07:08:45 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id DC097205ED for ; Thu, 4 May 2006 16:37:14 +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 C8D72205DC for ; Thu, 4 May 2006 16:37:14 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.167]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 16:38:19 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query regarding BYE request-URI Date: Thu, 4 May 2006 16:42:00 +0530 Message-ID: <2C7074A1A040E54DA31B3E72C052FD520245906C@BLR-EC-MBX04.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] query regarding BYE request-URI Thread-Index: AcZusZdcLPIzAT91SSapYXOmFW6VagAuQIoQ From: To: , X-OriginalArrivalTime: 04 May 2006 11:08:19.0573 (UTC) FILETIME=[0CEDC250:01C66F6B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092121960==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0092121960== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66F6B.0CD8AF94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66F6B.0CD8AF94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sudhir, U should use the contact header to construct BYE request-URI and not the record-route, Regards, Rathi =20 -----Original Message----- From: Sudhir [mailto:t.sudhirkumar@gmail.com]=20 Sent: Wednesday, May 03, 2006 6:29 PM To: sip@ietf.org Subject: [Sip] query regarding BYE request-URI Hi All, If UA received INVITE request with contact and record-route header, when UA want to built the BYE request. How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI? Any response is appreciated=20 Thanks in advance Sudhir =20 ------_=_NextPart_001_01C66F6B.0CD8AF94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Sudhir,
U should use the contact = header=20 to construct BYE request-URI
and not the record-route,
=
Regards,
Rathi
 
-----Original = Message-----
From: Sudhir=20 [mailto:t.sudhirkumar@gmail.com]
Sent: Wednesday, May 03, = 2006 6:29=20 PM
To: sip@ietf.org
Subject: [Sip] query regarding = BYE=20 request-URI

Hi All,

If UA received INVITE request with contact and record-route header, = when UA=20 want to built the BYE request.

How BYE request-URI is built? Should I use either record-route or = contact=20 header to construct BYE request-URI?


Any response = is=20 appreciated

Thanks in advance
Sudhir

 

------_=_NextPart_001_01C66F6B.0CD8AF94-- --===============0092121960== 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 --===============0092121960==-- From sip-bounces@ietf.org Thu May 04 07:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc4F-0002XS-MV; Thu, 04 May 2006 07:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc4E-0002XM-60 for sip@ietf.org; Thu, 04 May 2006 07:32:22 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbc4C-0006KA-OO for sip@ietf.org; Thu, 04 May 2006 07:32:22 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k44BWIPl019475; Thu, 4 May 2006 14:32:19 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 14:32:16 +0300 Received: from [172.21.39.63] ([172.21.39.63]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 May 2006 14:32:16 +0300 Message-ID: <4459E63E.9000300@nokia.com> Date: Thu, 04 May 2006 14:32:14 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Dean Willis Subject: Re: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt References: <8B1D53AEF7B03449A6D3771B3B7F850F02405DBF@esebe103.NOE.Nokia.com> <002d01c66e11$06fc5f60$31713b51@BEMBUSTER> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 11:32:16.0054 (UTC) FILETIME=[65235D60:01C66F6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Dean Willis wrote: > > > text records are almost universally supported, as they're quire easy to > add in a bind config file. > > However, most hosting-company front ends do not allow one to add them. > For example, Network Solutions Inc. doesn't let one add TXT, SRZ, PTR, > NAPTR, or anything else -- just A records, MX records, and CNAME records. Just to give one more datapoint, my DNS provider allows TXT as well as SRV (and AAAA of course ;), but not NAPTR. Since NAPTR is not strictly needed in SIP, I haven't found myself complaining too much. And BTW, my web-hosting != my DNS provider. There are, of course, other even free DNS providers that do allow full access to zone files, but clearly mileage varies with this one. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 04 07:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc5X-0002jg-QL; Thu, 04 May 2006 07:33:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc5W-0002jR-6Y for sip@ietf.org; Thu, 04 May 2006 07:33:42 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbc5F-0006L5-GS for sip@ietf.org; Thu, 04 May 2006 07:33:41 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.11.6) with ESMTP id k44BVdTV004218; Thu, 4 May 2006 17:01:39 +0530 In-Reply-To: <2C7074A1A040E54DA31B3E72C052FD520245906C@BLR-EC-MBX04.wipro.com> To: Subject: RE: [Sip] query regarding BYE request-URI MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: ujjal.sikdar@flextronicssoftware.com Date: Thu, 4 May 2006 17:01:24 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Ujjal Sikdar/BLR/HSS(Release 6.5.1|January 21, 2004) at 05/04/2006 05:01:46 PM, Serialize by Notes Client on Ujjal Sikdar/BLR/HSS(Release 6.5.1|January 21, 2004) at 05/04/2006 05:01:46 PM, Serialize complete at 05/04/2006 05:01:46 PM, S/MIME Sign failed at 05/04/2006 05:01:46 PM: The cryptographic key was not found, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/04/2006 05:00:21 PM, Serialize complete at 05/04/2006 05:00:21 PM X-Spam-Score: 0.3 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============1321746775==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1321746775== Content-Type: multipart/alternative; boundary="=_alternative 003F555D65257164_=" This is a multipart message in MIME format. --=_alternative 003F555D65257164_= Content-Type: text/plain; charset="US-ASCII" Hi, I agree with you, but you need to consider the case when the Proxy which is record-routing is strict router or loose router. If the record-routing Proxy is Loose router (next hop) then Contact header will be used as the request-URI. But if the record-routing Proxy is Strict router (next hop) then record-route will be used as the request-URI as per the routing policy. Rgds, Ujjal 05/04/2006 04:42 PM To , cc Subject RE: [Sip] query regarding BYE request-URI Hi Sudhir, U should use the contact header to construct BYE request-URI and not the record-route, Regards, Rathi -----Original Message----- From: Sudhir [mailto:t.sudhirkumar@gmail.com] Sent: Wednesday, May 03, 2006 6:29 PM To: sip@ietf.org Subject: [Sip] query regarding BYE request-URI Hi All, If UA received INVITE request with contact and record-route header, when UA want to built the BYE request. How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI? Any response is appreciated Thanks in advance Sudhir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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 003F555D65257164_= Content-Type: text/html; charset="US-ASCII"
Hi,

I agree with you, but you need to consider the case when the Proxy which is record-routing is strict router or loose router.
If the record-routing Proxy is Loose router (next hop) then Contact header will be used as the request-URI.
But if the record-routing Proxy is Strict router (next hop) then record-route will be used as the request-URI as per the
routing policy.

Rgds,
Ujjal



<rathi.kartheek@wipro.com>

05/04/2006 04:42 PM

To
<t.sudhirkumar@gmail.com>, <sip@ietf.org>
cc
Subject
RE: [Sip] query regarding BYE request-URI





Hi Sudhir,
U should use the contact header to construct BYE request-URI
and not the record-route,
Regards,
Rathi
 
-----Original Message-----
From: Sudhir [mailto:t.sudhirkumar@gmail.com]
Sent: Wednesday, May 03, 2006 6:29 PM
To: sip@ietf.org
Subject: [Sip] query regarding BYE request-URI

Hi All,

If UA received INVITE request with contact and record-route header, when UA want to built the BYE request.

How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI?


Any response is appreciated

Thanks in advance
Sudhir

 _______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 003F555D65257164_=-- --===============1321746775== 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 --===============1321746775==-- From sip-bounces@ietf.org Thu May 04 07:36:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc6X-0002xf-5Y; Thu, 04 May 2006 07:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbc6V-0002xP-Pd for sip@ietf.org; Thu, 04 May 2006 07:34:43 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbc6T-0006Nj-Dh for sip@ietf.org; Thu, 04 May 2006 07:34:43 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k44BYORp023150; Thu, 4 May 2006 17:04:25 +0530 To: rathi.kartheek@wipro.com, t.sudhirkumar@gmail.com, sip@ietf.org Subject: Re: [Sip] query regarding BYE request-URI References: <2C7074A1A040E54DA31B3E72C052FD520245906C@BLR-EC-MBX04.wipro.com> Message-ID: Date: Thu, 04 May 2006 17:03:30 +0530 From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146742080" MIME-Version: 1.0 In-Reply-To: <2C7074A1A040E54DA31B3E72C052FD520245906C@BLR-EC-MBX04.wipro.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ------=neXtPaRt_1146742080 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, The contact header may be used to construct the request uri, if the record route has loose route parameter. But if it is not there, the first entity in the record route must be used to construct the request uri and the route header of BYE should have the remaining record route headers and the contact uri should be added to the end of it. On Thu, 04 May 2006 16:42:00 +0530, wrote: > Hi Sudhir, > U should use the contact header to construct BYE request-URI > and not the record-route, > Regards, > Rathi > -----Original Message----- > From: Sudhir [mailto:t.sudhirkumar@gmail.com] > Sent: Wednesday, May 03, 2006 6:29 PM > To: sip@ietf.org > Subject: [Sip] query regarding BYE request-URI > > > > Hi All, > > If UA received INVITE request with contact and record-route header, when > UA want to built the BYE request. > > How BYE request-URI is built? Should I use either record-route or > contact header to construct BYE request-URI? > > > Any response is appreciated > > Thanks in advance > Sudhir > > -- Best Regards, Sudha V.S ------=neXtPaRt_1146742080 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146742080 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_1146742080-- From sip-bounces@ietf.org Thu May 04 07:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbcAJ-0003b0-C6; Thu, 04 May 2006 07:38:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbcAI-0003au-FF for sip@ietf.org; Thu, 04 May 2006 07:38:38 -0400 Received: from [202.144.91.190] (helo=axesmail.axestechnologies.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbcAE-0006Vb-Kp for sip@ietf.org; Thu, 04 May 2006 07:38:38 -0400 Received: from axesind ([192.168.5.3]) by axesmail.axestechnologies.com (8.12.10+Sun/8.12.10) with ESMTP id k44BcOte029013 for ; Thu, 4 May 2006 17:08:24 +0530 (IST) Received: from techmahindra.com (unknown [192.168.1.107]) by axesind (Postfix) with ESMTP id 474E4AD8A8 for ; Thu, 4 May 2006 16:41:13 +0530 (IST) Message-ID: <4459E74D.6080402@techmahindra.com> Date: Thu, 04 May 2006 17:06:45 +0530 From: Adarsh S G User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: RE: [Sip] query regarding BYE request-URI X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: 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="===============0724327875==" Errors-To: sip-bounces@ietf.org --===============0724327875== Content-Type: multipart/alternative; boundary="------------090808090203010905080407" --------------090808090203010905080407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi sudhir, u should use the Contact: header present in INVITE request. Regards Adarsh.S.Guler Hi All, If UA received INVITE request with contact and record-route header, when UA want to built the BYE request. How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI? Any response is appreciated Thanks in advance Sudhir --------------090808090203010905080407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi sudhir,

u should  use the Contact: header present in INVITE request.


Regards

Adarsh.S.Guler

Hi All,

If UA received INVITE request with contact and record-route header, when UA want to built the BYE request.

How BYE request-URI is built? Should I use either record-route or contact header to construct BYE request-URI?


Any response is appreciated

Thanks in advance
Sudhir


--------------090808090203010905080407-- --===============0724327875== 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 --===============0724327875==-- From sip-bounces@ietf.org Thu May 04 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeMa-0003gs-8Z; Thu, 04 May 2006 09:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazv3-0007L7-Ow for sip@ietf.org; Tue, 02 May 2006 14:48:21 -0400 Received: from web51310.mail.yahoo.com ([206.190.38.176]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fazv2-00011v-E5 for sip@ietf.org; Tue, 02 May 2006 14:48:21 -0400 Received: (qmail 6813 invoked by uid 60001); 2 May 2006 18:48:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yQTM6lLBAhFeAjVmIk+iJTg73ZQymoDnNcakmfLu5bfiNjTpBHMeIFmiqOGqNtikN9UsN/3fXDccobc0XUsj7uiimsgLzezhghBK5H2Ovfkn8WqLlSCBoHhbOgRiOl/rQxwBatmG9QPC9W6qvKLM6gWScFeI6Igmj2Br9hPISvU= ; Message-ID: <20060502184818.6811.qmail@web51310.mail.yahoo.com> Received: from [68.143.161.201] by web51310.mail.yahoo.com via HTTP; Tue, 02 May 2006 11:48:18 PDT Date: Tue, 2 May 2006 11:48:18 -0700 (PDT) From: "Siddhardha N. Garige" To: sip-implementors@cs.columbia.edu In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Thu, 04 May 2006 09:59:27 -0400 Cc: sip@ietf.org Subject: [Sip] Re: [Sip-implementors] Question regarding ptime attribute X-BeenThere: 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="===============1766816460==" Errors-To: sip-bounces@ietf.org --===============1766816460== Content-Type: multipart/alternative; boundary="0-1683310022-1146595698=:6077" Content-Transfer-Encoding: 8bit --0-1683310022-1146595698=:6077 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Udit, If you have only one "m=" field, ptime is applicable to all the entries in fmt list I did see someone previously explaining how to specify different times to different media formats. m=audio 10000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:10 m=audio 10000 RTP/AVP 4 a=rtpmap:4 G723/8000 a=ptime:30 m=audio 10000 RTP/AVP 18 a=rtpmap:18 G729/8000 a=ptime:20 Hope this helps.. Regards, Sid Udit_Goyal@3com.com wrote: Hi, If SDP contains following media line data: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 a=ptime: 30 Does it mean that it is using 30 ms packetization period for all the audio codecs, or only for codec with PT=98, rest all codecs use 20 ms. -Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ******************************************************* Siddhardha N. Garige Tampa, FL. Ph: (813)-298-4236. www.pbase.com/garige ******************************************************* --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-1683310022-1146595698=:6077 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Udit,

If you have only one "m=" field, ptime is applicable to all the entries in fmt list
I did see someone previously explaining how to specify different times to different media formats.

m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:10
m=audio 10000 RTP/AVP 4
a=rtpmap:4 G723/8000
a=ptime:30
m=audio 10000 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
Hope this helps..

Regards,
Sid

Udit_Goyal@3com.com wrote:
Hi,

If SDP contains following media line data:

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=ptime: 30

Does it mean that it is using 30 ms packetization period for all the audio
codecs, or only for codec with PT=98, rest all codecs use 20 ms.

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



*******************************************************
Siddhardha N. Garige
Tampa, FL.
Ph: (813)-298-4236.

www.pbase.com/garige

*******************************************************

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-1683310022-1146595698=:6077-- --===============1766816460== 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 --===============1766816460==-- From sip-bounces@ietf.org Thu May 04 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeMa-0003gz-UA; Thu, 04 May 2006 09:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbC0t-0004K5-0V for sip@ietf.org; Wed, 03 May 2006 03:43:11 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbC0r-0001SG-My for sip@ietf.org; Wed, 03 May 2006 03:43:10 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k437h8d0014028; Wed, 3 May 2006 02:43:08 -0500 Received: from hotsip.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k437h59C018310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 3 May 2006 01:43:07 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Fredrik Thulin" , "sip@ietf.org" Subject: RE: [Sip] Outbound: must Registrar also reuse flow? Date: Wed, 3 May 2006 09:43:05 +0200 Organization: Oracle Message-ID: <20060503094305720.00000002488@JANROGDENEW> In-Reply-To: <200604031724.56452.ft@it.su.se> X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.5608) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Thu, 04 May 2006 09:59:27 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. The interaction between an EP and a Registrar is not really the sa= me case as the interaction between UA-EP or UA-Registrar. This is not descr= ibed in the draft. /Jan = -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se] = Sent: den 3 april 2006 17:25 To: sip@ietf.org Subject: [Sip] Outbound: must Registrar also reuse flow? Hi In the following setup, if the client does Outbound and send a REGISTER towards the Registrar via the edge-proxy EP, UA --|-- EP -- Registrar NAT does the Registrar have to reuse the exact same flow to EP when a new request arrives at Registrar, targeted for UA? The EP obviously has to do so, but does the Registrar also have to? Section 6.1 definately says the Registrar must do so "The registrar MUST store enough information to uniquely identify the network flow over which the request arrived. " but I can't see the point in mandating the exact same flow being used to send subsequent requests from Registrar to EP, if both of them are on the open Internet? /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 Thu May 04 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeMa-0003gs-8Z; Thu, 04 May 2006 09:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazv3-0007L7-Ow for sip@ietf.org; Tue, 02 May 2006 14:48:21 -0400 Received: from web51310.mail.yahoo.com ([206.190.38.176]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fazv2-00011v-E5 for sip@ietf.org; Tue, 02 May 2006 14:48:21 -0400 Received: (qmail 6813 invoked by uid 60001); 2 May 2006 18:48:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yQTM6lLBAhFeAjVmIk+iJTg73ZQymoDnNcakmfLu5bfiNjTpBHMeIFmiqOGqNtikN9UsN/3fXDccobc0XUsj7uiimsgLzezhghBK5H2Ovfkn8WqLlSCBoHhbOgRiOl/rQxwBatmG9QPC9W6qvKLM6gWScFeI6Igmj2Br9hPISvU= ; Message-ID: <20060502184818.6811.qmail@web51310.mail.yahoo.com> Received: from [68.143.161.201] by web51310.mail.yahoo.com via HTTP; Tue, 02 May 2006 11:48:18 PDT Date: Tue, 2 May 2006 11:48:18 -0700 (PDT) From: "Siddhardha N. Garige" To: sip-implementors@cs.columbia.edu In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Thu, 04 May 2006 09:59:27 -0400 Cc: sip@ietf.org Subject: [Sip] Re: [Sip-implementors] Question regarding ptime attribute X-BeenThere: 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="===============1766816460==" Errors-To: sip-bounces@ietf.org --===============1766816460== Content-Type: multipart/alternative; boundary="0-1683310022-1146595698=:6077" Content-Transfer-Encoding: 8bit --0-1683310022-1146595698=:6077 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Udit, If you have only one "m=" field, ptime is applicable to all the entries in fmt list I did see someone previously explaining how to specify different times to different media formats. m=audio 10000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=ptime:10 m=audio 10000 RTP/AVP 4 a=rtpmap:4 G723/8000 a=ptime:30 m=audio 10000 RTP/AVP 18 a=rtpmap:18 G729/8000 a=ptime:20 Hope this helps.. Regards, Sid Udit_Goyal@3com.com wrote: Hi, If SDP contains following media line data: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 a=ptime: 30 Does it mean that it is using 30 ms packetization period for all the audio codecs, or only for codec with PT=98, rest all codecs use 20 ms. -Udit _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors ******************************************************* Siddhardha N. Garige Tampa, FL. Ph: (813)-298-4236. www.pbase.com/garige ******************************************************* --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-1683310022-1146595698=:6077 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Udit,

If you have only one "m=" field, ptime is applicable to all the entries in fmt list
I did see someone previously explaining how to specify different times to different media formats.

m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:10
m=audio 10000 RTP/AVP 4
a=rtpmap:4 G723/8000
a=ptime:30
m=audio 10000 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
Hope this helps..

Regards,
Sid

Udit_Goyal@3com.com wrote:
Hi,

If SDP contains following media line data:

m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=ptime: 30

Does it mean that it is using 30 ms packetization period for all the audio
codecs, or only for codec with PT=98, rest all codecs use 20 ms.

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



*******************************************************
Siddhardha N. Garige
Tampa, FL.
Ph: (813)-298-4236.

www.pbase.com/garige

*******************************************************

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-1683310022-1146595698=:6077-- --===============1766816460== 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 --===============1766816460==-- From sip-bounces@ietf.org Thu May 04 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeMa-0003gz-UA; Thu, 04 May 2006 09:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbC0t-0004K5-0V for sip@ietf.org; Wed, 03 May 2006 03:43:11 -0400 Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbC0r-0001SG-My for sip@ietf.org; Wed, 03 May 2006 03:43:10 -0400 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k437h8d0014028; Wed, 3 May 2006 02:43:08 -0500 Received: from hotsip.com (dhcp-22-3-185.se.oracle.com [144.22.3.185]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k437h59C018310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 3 May 2006 01:43:07 -0600 From: =?iso-8859-1?B?IkphbiBS9mdkZSI=?= To: "Fredrik Thulin" , "sip@ietf.org" Subject: RE: [Sip] Outbound: must Registrar also reuse flow? Date: Wed, 3 May 2006 09:43:05 +0200 Organization: Oracle Message-ID: <20060503094305720.00000002488@JANROGDENEW> In-Reply-To: <200604031724.56452.ft@it.su.se> X-Mailer: Oracle Connector for Outlook 10.1.2.0.0 71006 (11.0.5608) X-Accept-Language: sv-se, sv MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Thu, 04 May 2006 09:59:27 -0400 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "jan.rogde@oracle.com" List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. The interaction between an EP and a Registrar is not really the sa= me case as the interaction between UA-EP or UA-Registrar. This is not descr= ibed in the draft. /Jan = -----Original Message----- From: Fredrik Thulin [mailto:ft@it.su.se] = Sent: den 3 april 2006 17:25 To: sip@ietf.org Subject: [Sip] Outbound: must Registrar also reuse flow? Hi In the following setup, if the client does Outbound and send a REGISTER towards the Registrar via the edge-proxy EP, UA --|-- EP -- Registrar NAT does the Registrar have to reuse the exact same flow to EP when a new request arrives at Registrar, targeted for UA? The EP obviously has to do so, but does the Registrar also have to? Section 6.1 definately says the Registrar must do so "The registrar MUST store enough information to uniquely identify the network flow over which the request arrived. " but I can't see the point in mandating the exact same flow being used to send subsequent requests from Registrar to EP, if both of them are on the open Internet? /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 Thu May 04 12:14:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgRZ-00041p-TW; Thu, 04 May 2006 12:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgRY-00041I-0f for sip@ietf.org; Thu, 04 May 2006 12:12:44 -0400 Received: from bzq-114-71-192.cust.bezeqint.net ([192.114.71.192] helo=calllan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbgRV-00020A-Ku for sip@ietf.org; Thu, 04 May 2006 12:12:43 -0400 Received: from yonicomp (bzq-88-153-112-56.red.bezeqint.net [88.153.112.56]) by calllan.com (calllan.com [192.114.71.192]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 14-md50000000019.tmp for ; Thu, 04 May 2006 19:16:38 +0200 From: "Yonatan Doron" To: Date: Thu, 4 May 2006 19:11:01 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZvnbeYFXzoEfrHRli10v4pOASyVg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Processed: calllan.com, Thu, 04 May 2006 19:16:38 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 88.153.112.56 X-Return-Path: yoni@usbphone.com X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] SIP Call Hold 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: , Content-Type: multipart/mixed; boundary="===============0621414389==" Errors-To: sip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0621414389== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C66FAE.7B9569E0" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C66FAE.7B9569E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit According to my understanding, a UA which receives a request for call-hold ( an INVITE with SDP containing the media field "sendonly"), may accept the hold by sending a 200OK reply containing the SDP media field "recvonly". The problem is that the SIP clients I have tried, all answer a hold request with a "sendrecv" field, which actually means that they *reject* the request for hold (they do not agree to only receive the stream). If this is true, how can my client support this backward behaviour ? ------=_NextPart_000_0000_01C66FAE.7B9569E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
According to my=20 understanding, a UA which receives a request for call-hold ( an = INVITE with=20 SDP containing the media field "sendonly"), may accept the=20 hold by sending a 200OK reply containing the SDP media = field=20 "recvonly".
The = problem is that=20 the SIP clients I have tried, all answer a hold request with a = "sendrecv"=20 field, which actually means that they *reject* the request for hold = (they=20 do not agree to only receive the stream).
 
If this is true, how can my client support this = backward=20 behaviour ?
------=_NextPart_000_0000_01C66FAE.7B9569E0-- --===============0621414389== 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 --===============0621414389==-- From sip-bounces@ietf.org Thu May 04 16:57:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkql-0003YG-A7; Thu, 04 May 2006 16:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkqj-0003WH-S9 for sip@ietf.org; Thu, 04 May 2006 16:55:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbkqj-0007H1-1B for sip@ietf.org; Thu, 04 May 2006 16:55:01 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CEE464F0001; Thu, 4 May 2006 22:54:59 +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, 4 May 2006 22:54:59 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 22:54: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Thu, 4 May 2006 22:54:58 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0E81@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZvZ1E1Jny3LEieSRKmLAILv0aFxgAVUapA From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jesske, R" , X-OriginalArrivalTime: 04 May 2006 20:54:59.0332 (UTC) FILETIME=[019EBC40:01C66FBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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, >From the safeness point of view, I thought we already agreed (at least I = haven't heard any disagreement) that doing it would not be unsafe, since = the arguments that modifying the To and/or From header URI would affect = the transaction logic were not true. Regards, Christer=20 -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com]=20 Sent: 4. toukokuuta 2006 13:39 To: Jesske, R; sip@ietf.org Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Roland, Well, you would need to convince the community that this is a worthwhile = and safe thing to do. Agreement to date is only to change From and To = header field URIs in mid-dialog requests. Changing the To header field = URI in a response would require separate agreement. I suggest you write = an I-D and try to get backing. However, I fear you will encounter strong = opposition. Regards, John=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: 04 May 2006 09:37 > To: Elwell, John; sip@ietf.org > Cc: chister.holmberg@ericsson.com; > sebastien.garcin@francetelecom.com; Alexeitsev, D; esasaki@NTT-AT.COM > Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 > Dear John et all, > I'm sorry to go again into the opposite oppinion but I'm still in=20 > favour of enhancing the draft to provide identity in the To header=20 > field URI of a response. >=20 > I don't know if we have to rediscuss all the possibilities and=20 > assumptions. But fact is that such a to header change would be useful=20 > for some services. >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > An: sip@ietf.org > > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > There are three open issues in this draft and a fourth that > was raised > > subsequently. This mail initiates discussion on the first issue. I=20 > > will initiate discussion on the other three issues in separate=20 > > mails. > >=20 > > Issue 1 appears in section 5 and concerns the fact that this draft=20 > > intentionally does not address response identity, and therefore the=20 > > identity of a dialog-forming responder to an INVITE request is=20 > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > direction rather than in the response to the INVITE request. The=20 > > open issue is stated as: > >=20 > > "OPEN ISSUE. Should this be extended to allow a URI in the To > > header field of a response to change compared with > the To header > > field in a request? This could convey a connected > identity in a > > response to an INVITE request, but it would not be=20 > > authenticated. > > Authentication would have to rely on transitive trust, which=20 > > might > > be feasible in a closed environment where the sips > URI scheme is > > used." > >=20 > > There was considerable list discussion on this shortly after > > IETF65 with no > > resolution. I won't attempt to summarise it. My opinion > (for what it's > > worth) is as follows. > >=20 > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header=20 > > field URIs throughout a dialog (i.e., it anticipates that these will = > > be allowed to change mid-dialog), it says nothing to warn of any=20 > > future removal of the requirement that the To header field URI in=20 > > the response be the same as that in the request. Therefore I believe = > > it would be dangerous to specify such a change to the To header=20 > > field URI. > >=20 > > 2. The prime motivation for this draft was to provide authenticated=20 > > identity, i.e., to complement the sip-identity draft. An identity in = > > the To header field of a response cannot be authenticated, for=20 > > reasons stated many times on this list and at meetings. Therefore,=20 > > at least in the Internet, a response identity would have little=20 > > value. > >=20 > > 3. A comprehensive list of reasons for not going down that path were = > > given by Jon Peterson (editor of the Identity draft) in a message to = > > this list on 5th April. > >=20 > > 4. In closed environments an unauthenticated response identity might = > > have some value. But this could be achieved using > P-Asserted-Identity, say, > > rather than bending the rules for To headers in responses. > >=20 > > Therefore I am NOT in favour of enhancing the draft to provide=20 > > identity in the To header field URI of a response. Can people agree=20 > > to this resolution of the issue? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: 26 April 2006 20:50 > > > To: i-d-announce@ietf.org > > > Cc: sip@ietf.org > > > Subject: [Sip] I-D ACTION:draft-ietf-sip-connected-identity-00.txt > > >=20 > > > A New Internet-Draft is available from the on-line Internet-Drafts = > > > directories. > > > This draft is a work item of the Session Initiation Protocol=20 > > > Working Group of the IETF. > > >=20 > > > Title : Connected Identity in the Session=20 > > > Initiation Protocol (SIP) > > > Author(s) : J. Elwell > > > Filename : draft-ietf-sip-connected-identity-00.txt > > > Pages : 20 > > > Date : 2006-4-26 > > > =09 > > > Because of retargeting of a Session Initiation Protocol > > > (SIP) dialog- > > > forming request, the UAS can have a different identity > > from that in > > > the To header. This document provides a means for that UA to=20 > > > 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 PSTN > > > behind a gateway. This document normatively updates RFC > > > 3261 (SIP). > > > This work is being discussed on the sip@ietf.org mailing list. > > >=20 > > >=20 > > >=20 > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > dentity-00.txt > > >=20 > > > 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=20 > > > body of the message. > > > You can also visit > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > >=20 > > >=20 > > > Internet-Drafts are also available by anonymous FTP. Login with=20 > > > the username "anonymous" and a password of your e-mail address.=20 > > > After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-sip-connected-identity-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 > > >=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-ietf-sip-connected-identity-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=20 > > > 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. > > > =09 > > > =09 > > > 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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 04 18:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbmaf-0003b2-5p; Thu, 04 May 2006 18:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbmae-0003ax-2V for sip@ietf.org; Thu, 04 May 2006 18:46:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbmac-0003IR-MT for sip@ietf.org; Thu, 04 May 2006 18:46:32 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 15:46:08 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="272892788:sNHT3579535388" 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 k44Mk6VI021841; Thu, 4 May 2006 15:46:06 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:46:05 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:46:05 -0400 Message-ID: <445A842D.3040600@cisco.com> Date: Thu, 04 May 2006 18:46:05 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yonatan Doron Subject: Re: [Sip] SIP Call Hold reply References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 22:46:05.0540 (UTC) FILETIME=[86FD5A40:01C66FCC] 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 The behavior you describe is non-conforming to 3264. So the UA is probably only compliant to 2543, or something interim between 2543 and 3261. The best recovery action in this case is to fall back to the 2543 hold mechanism - send an offer with c=0.0.0.0. Paul Yonatan Doron wrote: > According to my understanding, a UA which receives a request for > call-hold ( an INVITE with SDP containing the media field > "sendonly"), may accept the hold by sending a 200OK reply containing the > SDP media field "recvonly". > The problem is that the SIP clients I have tried, all answer a hold > request with a "sendrecv" field, which actually means that they *reject* > the request for hold (they do not agree to only receive the stream). > > If this is true, how can my client support this backward behaviour ? > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 00:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbrq7-0000DZ-Po; Fri, 05 May 2006 00:22:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbrq6-0000DU-SH for sip@ietf.org; Fri, 05 May 2006 00:22:50 -0400 Received: from smtp.ycn.com ([212.88.160.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbrq4-00074w-Ig for sip@ietf.org; Fri, 05 May 2006 00:22:50 -0400 Received: from notebook (85-90-133-128.DSL.ycn.com [85.90.133.128]) by smtp.ycn.com (Postfix) with ESMTP id 09EBAA600D; Fri, 5 May 2006 06:22:46 +0200 (CEST) From: "Franz Edler" To: "'Yonatan Doron'" , Subject: AW: [Sip] SIP Call Hold reply Date: Fri, 5 May 2006 06:22:48 +0200 Message-ID: <005201c66ffb$910f6ee0$0600a8c0@notebook> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcZvnbeYFXzoEfrHRli10v4pOASyVgAXdQ4Q 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 > According to my understanding, a UA which receives a request for > call-hold ( an INVITE with SDP containing the media field "sendonly"), > may accept the hold by sending a 200OK reply containing the SDP media > field "recvonly". Yes. That's the rule. > The problem is that the SIP clients I have tried, all answer a hold > request with a "sendrecv" field, which actually means that they > *reject* the request for hold (they do not agree to only receive the stream). Fortunately I cannot share your experience. You should claim standard compliance from the vendors. Franz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 02:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbtUg-00033K-1U; Fri, 05 May 2006 02:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbtUe-00033F-Q4 for sip@ietf.org; Fri, 05 May 2006 02:08:48 -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 1FbtUc-0002he-4Y for sip@ietf.org; Fri, 05 May 2006 02:08:48 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYS00C013R7AP@siemenscomms.co.uk> for sip@ietf.org; Fri, 05 May 2006 07:09: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 <0IYS005FV3R6H2@siemenscomms.co.uk>; Fri, 05 May 2006 07:09:07 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 05 May 2006 07:08:39 +0100 Content-return: allowed Date: Fri, 05 May 2006 07:08:38 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Christer Holmberg (JO/LMF)" , "Jesske, R" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D3E3AA@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Christer, Technically it might work, but RFC3261 neither gives permission to = change the To header field URI in a response nor hints at a future lifting of = this restriction. John > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 04 May 2006 21:55 > To: Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 >=20 > Hi, >=20 > From the safeness point of view, I thought we already agreed=20 > (at least I haven't heard any disagreement) that doing it=20 > would not be unsafe, since the arguments that modifying the=20 > To and/or From header URI would affect the transaction logic=20 > were not true. >=20 > Regards, >=20 > Christer=20 >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 4. toukokuuta 2006 13:39 > To: Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 > Roland, >=20 > Well, you would need to convince the community that this is a=20 > worthwhile and safe thing to do. Agreement to date is only to=20 > change From and To header field URIs in mid-dialog requests.=20 > Changing the To header field URI in a response would require=20 > separate agreement. I suggest you write an I-D and try to get=20 > backing. However, I fear you will encounter strong opposition. >=20 > Regards, >=20 > John=20 >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 04 May 2006 09:37 > > To: Elwell, John; sip@ietf.org > > Cc: chister.holmberg@ericsson.com; > > sebastien.garcin@francetelecom.com; Alexeitsev, D;=20 > esasaki@NTT-AT.COM > > Subject: AW: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > > Dear John et all, > > I'm sorry to go again into the opposite oppinion but I'm still in=20 > > favour of enhancing the draft to provide identity in the To header=20 > > field URI of a response. > >=20 > > I don't know if we have to rediscuss all the possibilities and=20 > > assumptions. But fact is that such a to header change would=20 > be useful=20 > > for some services. > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > An: sip@ietf.org > > > Betreff: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > > There are three open issues in this draft and a fourth that > > was raised > > > subsequently. This mail initiates discussion on the first=20 > issue. I=20 > > > will initiate discussion on the other three issues in separate=20 > > > mails. > > >=20 > > > Issue 1 appears in section 5 and concerns the fact that=20 > this draft=20 > > > intentionally does not address response identity, and=20 > therefore the=20 > > > identity of a dialog-forming responder to an INVITE request is=20 > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > direction rather than in the response to the INVITE request. The=20 > > > open issue is stated as: > > >=20 > > > "OPEN ISSUE. Should this be extended to allow a=20 > URI in the To > > > header field of a response to change compared with > > the To header > > > field in a request? This could convey a connected > > identity in a > > > response to an INVITE request, but it would not be=20 > > > authenticated. > > > Authentication would have to rely on transitive=20 > trust, which=20 > > > might > > > be feasible in a closed environment where the sips > > URI scheme is > > > used." > > >=20 > > > There was considerable list discussion on this shortly after > > > IETF65 with no > > > resolution. I won't attempt to summarise it. My opinion > > (for what it's > > > worth) is as follows. > > >=20 > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header=20 > > > field URIs throughout a dialog (i.e., it anticipates that=20 > these will=20 > > > be allowed to change mid-dialog), it says nothing to warn of any=20 > > > future removal of the requirement that the To header field URI in = > > > the response be the same as that in the request.=20 > Therefore I believe=20 > > > it would be dangerous to specify such a change to the To header=20 > > > field URI. > > >=20 > > > 2. The prime motivation for this draft was to provide=20 > authenticated=20 > > > identity, i.e., to complement the sip-identity draft. An=20 > identity in=20 > > > the To header field of a response cannot be authenticated, for=20 > > > reasons stated many times on this list and at meetings.=20 > Therefore,=20 > > > at least in the Internet, a response identity would have little=20 > > > value. > > >=20 > > > 3. A comprehensive list of reasons for not going down=20 > that path were=20 > > > given by Jon Peterson (editor of the Identity draft) in a=20 > message to=20 > > > this list on 5th April. > > >=20 > > > 4. In closed environments an unauthenticated response=20 > identity might=20 > > > have some value. But this could be achieved using > > P-Asserted-Identity, say, > > > rather than bending the rules for To headers in responses. > > >=20 > > > Therefore I am NOT in favour of enhancing the draft to provide=20 > > > identity in the To header field URI of a response. Can=20 > people agree=20 > > > to this resolution of the issue? > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org] > > > > Sent: 26 April 2006 20:50 > > > > To: i-d-announce@ietf.org > > > > Cc: sip@ietf.org > > > > Subject: [Sip] I-D=20 > ACTION:draft-ietf-sip-connected-identity-00.txt > > > >=20 > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > > directories. > > > > This draft is a work item of the Session Initiation Protocol=20 > > > > Working Group of the IETF. > > > >=20 > > > > Title : Connected Identity in the Session=20 > > > > Initiation Protocol (SIP) > > > > Author(s) : J. Elwell > > > > Filename :=20 > draft-ietf-sip-connected-identity-00.txt > > > > Pages : 20 > > > > Date : 2006-4-26 > > > > =09 > > > > Because of retargeting of a Session Initiation Protocol > > > > (SIP) dialog- > > > > forming request, the UAS can have a different identity > > > from that in > > > > the To header. This document provides a means for=20 > that UA to=20 > > > > 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 PSTN > > > > behind a gateway. This document normatively updates RFC > > > > 3261 (SIP). > > > > This work is being discussed on the sip@ietf.org=20 > mailing list. > > > >=20 > > > >=20 > > > >=20 > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > dentity-00.txt > > > >=20 > > > > 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=20 > > > > body of the message. > > > > You can also visit > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > to change your subscription settings. > > > >=20 > > > >=20 > > > > 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-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 > > > >=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-ietf-sip-connected-identity-00.txt". > > > > =09 > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility.=20 > To use this > > > > feature, insert the command "ENCODING mime"=20 > before the "FILE" > > > > command. To decode the response(s), you will=20 > need "munpack" or > > > > a MIME-compliant mail reader. Different=20 > MIME-compliant mail=20 > > > > readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which=20 > have been split > > > > up into multiple messages), so check your local=20 > documentation on > > > > how to manipulate these messages. > > > > =09 > > > > =09 > > > > Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > > implementation to automatically retrieve the ASCII=20 > 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 Use = > > > 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=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 May 05 03:24:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbue8-00041F-6n; Fri, 05 May 2006 03:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbue6-000418-Cl for sip@ietf.org; Fri, 05 May 2006 03:22:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbue4-0004yA-Gy for sip@ietf.org; Fri, 05 May 2006 03:22:38 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6ACB54F0001; Fri, 5 May 2006 09:22:35 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:22:35 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:22:35 +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] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 5 May 2006 09:22:34 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0E87@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZwCl86GLyUROQVS3+j5YVUy5v4aAACftKw From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jesske, R" , X-OriginalArrivalTime: 05 May 2006 07:22:35.0208 (UTC) FILETIME=[AE456C80:01C67014] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Technically it might work, but RFC3261 neither gives permission to = change the To header field URI in a response nor hints at a future = lifting of this=20 >restriction. So, where does RFC3261 give permisson to change the To header field URI = later in a request, then???=20 I thought the changing of the URI was something that THIS GROUP has = agreed is to be allowed. Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 04 May 2006 21:55 > To: Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 >=20 > Hi, >=20 > From the safeness point of view, I thought we already agreed (at least = > I haven't heard any disagreement) that doing it would not be unsafe,=20 > since the arguments that modifying the To and/or From header URI would = > affect the transaction logic were not true. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 4. toukokuuta 2006 13:39 > To: Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 > Roland, >=20 > Well, you would need to convince the community that this is a=20 > worthwhile and safe thing to do. Agreement to date is only to change=20 > From and To header field URIs in mid-dialog requests. > Changing the To header field URI in a response would require separate=20 > agreement. I suggest you write an I-D and try to get backing. However, = > I fear you will encounter strong opposition. >=20 > Regards, >=20 > John >=20 > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 04 May 2006 09:37 > > To: Elwell, John; sip@ietf.org > > Cc: chister.holmberg@ericsson.com; > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > esasaki@NTT-AT.COM > > Subject: AW: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > >=20 > > Dear John et all, > > I'm sorry to go again into the opposite oppinion but I'm still in=20 > > favour of enhancing the draft to provide identity in the To header=20 > > field URI of a response. > >=20 > > I don't know if we have to rediscuss all the possibilities and=20 > > assumptions. But fact is that such a to header change would > be useful > > for some services. > >=20 > > Best Regards > >=20 > > Roland > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > An: sip@ietf.org > > > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > > There are three open issues in this draft and a fourth that > > was raised > > > subsequently. This mail initiates discussion on the first > issue. I > > > will initiate discussion on the other three issues in separate=20 > > > mails. > > >=20 > > > Issue 1 appears in section 5 and concerns the fact that > this draft > > > intentionally does not address response identity, and > therefore the > > > identity of a dialog-forming responder to an INVITE request is=20 > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > direction rather than in the response to the INVITE request. The=20 > > > open issue is stated as: > > >=20 > > > "OPEN ISSUE. Should this be extended to allow a > URI in the To > > > header field of a response to change compared with > > the To header > > > field in a request? This could convey a connected > > identity in a > > > response to an INVITE request, but it would not be=20 > > > authenticated. > > > Authentication would have to rely on transitive > trust, which > > > might > > > be feasible in a closed environment where the sips > > URI scheme is > > > used." > > >=20 > > > There was considerable list discussion on this shortly after > > > IETF65 with no > > > resolution. I won't attempt to summarise it. My opinion > > (for what it's > > > worth) is as follows. > > >=20 > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header=20 > > > field URIs throughout a dialog (i.e., it anticipates that > these will > > > be allowed to change mid-dialog), it says nothing to warn of any=20 > > > future removal of the requirement that the To header field URI in=20 > > > the response be the same as that in the request. > Therefore I believe > > > it would be dangerous to specify such a change to the To header=20 > > > field URI. > > >=20 > > > 2. The prime motivation for this draft was to provide > authenticated > > > identity, i.e., to complement the sip-identity draft. An > identity in > > > the To header field of a response cannot be authenticated, for=20 > > > reasons stated many times on this list and at meetings. > Therefore, > > > at least in the Internet, a response identity would have little=20 > > > value. > > >=20 > > > 3. A comprehensive list of reasons for not going down > that path were > > > given by Jon Peterson (editor of the Identity draft) in a > message to > > > this list on 5th April. > > >=20 > > > 4. In closed environments an unauthenticated response > identity might > > > have some value. But this could be achieved using > > P-Asserted-Identity, say, > > > rather than bending the rules for To headers in responses. > > >=20 > > > Therefore I am NOT in favour of enhancing the draft to provide=20 > > > identity in the To header field URI of a response. Can > people agree > > > to this resolution of the issue? > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: 26 April 2006 20:50 > > > > To: i-d-announce@ietf.org > > > > Cc: sip@ietf.org > > > > Subject: [Sip] I-D > ACTION:draft-ietf-sip-connected-identity-00.txt > > > >=20 > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > This draft is a work item of the Session Initiation Protocol=20 > > > > Working Group of the IETF. > > > >=20 > > > > Title : Connected Identity in the Session=20 > > > > Initiation Protocol (SIP) > > > > Author(s) : J. Elwell > > > > Filename :=20 > draft-ietf-sip-connected-identity-00.txt > > > > Pages : 20 > > > > Date : 2006-4-26 > > > > =09 > > > > Because of retargeting of a Session Initiation Protocol > > > > (SIP) dialog- > > > > forming request, the UAS can have a different identity > > > from that in > > > > the To header. This document provides a means for > that 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 PSTN > > > > behind a gateway. This document normatively updates RFC > > > > 3261 (SIP). > > > > This work is being discussed on the sip@ietf.org > mailing list. > > > >=20 > > > >=20 > > > >=20 > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > dentity-00.txt > > > >=20 > > > > 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=20 > > > > body of the message. > > > > You can also visit > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > to change your subscription settings. > > > >=20 > > > >=20 > > > > Internet-Drafts are also available by anonymous FTP. Login with=20 > > > > 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-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 > > > >=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-ietf-sip-connected-identity-00.txt". > > > > =09 > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility.=20 > To use this > > > > feature, insert the command "ENCODING mime"=20 > 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. > > > > =09 > > > > =09 > > > > Below is the data which will enable a MIME compliant > mail reader > > > > implementation to automatically retrieve the ASCII > version of the > > > > 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 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 03:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuuF-0006NT-GP; Fri, 05 May 2006 03:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuuD-0006LX-S2 for sip@ietf.org; Fri, 05 May 2006 03:39:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbuu8-0005jU-O6 for sip@ietf.org; Fri, 05 May 2006 03:39:14 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1BFB04F0001; Fri, 5 May 2006 09:39:12 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:39:12 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:39:11 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 5 May 2006 09:39:11 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0E8A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZwFgPJewUZ+H2JQF+30JC3umNinQAAMpQQ From: "Christer Holmberg \(JO/LMF\)" To: "Jeroen van Bemmel" , "Elwell, John" , "Jesske, R" , X-OriginalArrivalTime: 05 May 2006 07:39:11.0862 (UTC) FILETIME=[0052C160:01C67017] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >RFC3261 Section 12.2.1.1: "[...] It is expected that mandatory = reflection of the original To and From URI in mid-dialog requests will = be deprecated in a=20 >subsequent revision of this specification." Ok, I appologize for missing that. However, that doesn't prevent us from also allowing to change the URI in = responses in a "subsequence revision". Regards, Christer ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" ; "Jesske, R"=20 ; Cc: ; Sent: Friday, May 05, 2006 9:22 AM Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Hi, >Technically it might work, but RFC3261 neither gives permission to = change=20 >the To header field URI in a response nor hints at a future lifting of = this >restriction. So, where does RFC3261 give permisson to change the To header field URI=20 later in a request, then??? I thought the changing of the URI was something that THIS GROUP has = agreed=20 is to be allowed. Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 04 May 2006 21:55 > To: Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > > Hi, > > From the safeness point of view, I thought we already agreed (at least > I haven't heard any disagreement) that doing it would not be unsafe, > since the arguments that modifying the To and/or From header URI would > affect the transaction logic were not true. > > Regards, > > Christer > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 4. toukokuuta 2006 13:39 > To: Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > Roland, > > Well, you would need to convince the community that this is a > worthwhile and safe thing to do. Agreement to date is only to change > From and To header field URIs in mid-dialog requests. > Changing the To header field URI in a response would require separate > agreement. I suggest you write an I-D and try to get backing. However, > I fear you will encounter strong opposition. > > Regards, > > John > > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 04 May 2006 09:37 > > To: Elwell, John; sip@ietf.org > > Cc: chister.holmberg@ericsson.com; > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > esasaki@NTT-AT.COM > > Subject: AW: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > > > > Dear John et all, > > I'm sorry to go again into the opposite oppinion but I'm still in > > favour of enhancing the draft to provide identity in the To header > > field URI of a response. > > > > I don't know if we have to rediscuss all the possibilities and > > assumptions. But fact is that such a to header change would > be useful > > for some services. > > > > Best Regards > > > > Roland > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > An: sip@ietf.org > > > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > > > > > > > > There are three open issues in this draft and a fourth that > > was raised > > > subsequently. This mail initiates discussion on the first > issue. I > > > will initiate discussion on the other three issues in separate > > > mails. > > > > > > Issue 1 appears in section 5 and concerns the fact that > this draft > > > intentionally does not address response identity, and > therefore the > > > identity of a dialog-forming responder to an INVITE request is > > > conveyed in a separate request (e.g., UPDATE) in the reverse > > > direction rather than in the response to the INVITE request. The > > > open issue is stated as: > > > > > > "OPEN ISSUE. Should this be extended to allow a > URI in the To > > > header field of a response to change compared with > > the To header > > > field in a request? This could convey a connected > > identity in a > > > response to an INVITE request, but it would not be > > > authenticated. > > > Authentication would have to rely on transitive > trust, which > > > might > > > be feasible in a closed environment where the sips > > URI scheme is > > > used." > > > > > > There was considerable list discussion on this shortly after > > > IETF65 with no > > > resolution. I won't attempt to summarise it. My opinion > > (for what it's > > > worth) is as follows. > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header > > > field URIs throughout a dialog (i.e., it anticipates that > these will > > > be allowed to change mid-dialog), it says nothing to warn of any > > > future removal of the requirement that the To header field URI in > > > the response be the same as that in the request. > Therefore I believe > > > it would be dangerous to specify such a change to the To header > > > field URI. > > > > > > 2. The prime motivation for this draft was to provide > authenticated > > > identity, i.e., to complement the sip-identity draft. An > identity in > > > the To header field of a response cannot be authenticated, for > > > reasons stated many times on this list and at meetings. > Therefore, > > > at least in the Internet, a response identity would have little > > > value. > > > > > > 3. A comprehensive list of reasons for not going down > that path were > > > given by Jon Peterson (editor of the Identity draft) in a > message to > > > this list on 5th April. > > > > > > 4. In closed environments an unauthenticated response > identity might > > > have some value. But this could be achieved using > > P-Asserted-Identity, say, > > > rather than bending the rules for To headers in responses. > > > > > > Therefore I am NOT in favour of enhancing the draft to provide > > > identity in the To header field URI of a response. Can > people agree > > > to this resolution of the issue? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: 26 April 2006 20:50 > > > > To: i-d-announce@ietf.org > > > > Cc: sip@ietf.org > > > > Subject: [Sip] I-D > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > This draft is a work item of the Session Initiation Protocol > > > > Working Group of the IETF. > > > > > > > > Title : Connected Identity in the Session > > > > Initiation Protocol (SIP) > > > > Author(s) : J. Elwell > > > > Filename : > draft-ietf-sip-connected-identity-00.txt > > > > Pages : 20 > > > > Date : 2006-4-26 > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > (SIP) dialog- > > > > forming request, the UAS can have a different identity > > > from that in > > > > the To header. This document provides a means for > that 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 PSTN > > > > behind a gateway. This document normatively updates RFC > > > > 3261 (SIP). > > > > This work is being discussed on the sip@ietf.org > mailing list. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > dentity-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-connected-identity-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-connected-identity-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 > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 05 03:42:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuvY-00072g-Qj; Fri, 05 May 2006 03:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuvU-00071G-Lw for sip@ietf.org; Fri, 05 May 2006 03:40:36 -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 1FbuvU-0005pE-JG for sip@ietf.org; Fri, 05 May 2006 03:40:36 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbumY-00087R-I6 for sip@ietf.org; Fri, 05 May 2006 03:31:25 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYS009017KXL4@siemenscomms.co.uk> for sip@ietf.org; Fri, 05 May 2006 08:31:45 +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 <0IYS0084F7KWQQ@siemenscomms.co.uk>; Fri, 05 May 2006 08:31:44 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 05 May 2006 08:31:17 +0100 Content-return: allowed Date: Fri, 05 May 2006 08:31:16 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Christer Holmberg (JO/LMF)" , "Jesske, R" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D3E3E3@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Christer, > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 05 May 2006 08:23 > To: Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 >=20 > Hi,=20 >=20 > >Technically it might work, but RFC3261 neither gives=20 > permission to change the To header field URI in a response=20 > nor hints at a future lifting of this=20 > >restriction. >=20 > So, where does RFC3261 give permisson to change the To header=20 > field URI later in a request, then???=20 [JRE] The reference is given in section 5 of my draft. >=20 > I thought the changing of the URI was something that THIS=20 > GROUP has agreed is to be allowed. [JRE] Yes, this group agreed on what was anticipated by RFC3261. This decision and the statement in RFC3261 apply only to mid-dialog = requests. John >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 04 May 2006 21:55 > > To: Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > Hi, > >=20 > > From the safeness point of view, I thought we already=20 > agreed (at least=20 > > I haven't heard any disagreement) that doing it would not=20 > be unsafe,=20 > > since the arguments that modifying the To and/or From=20 > header URI would=20 > > affect the transaction logic were not true. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 4. toukokuuta 2006 13:39 > > To: Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > > Roland, > >=20 > > Well, you would need to convince the community that this is a=20 > > worthwhile and safe thing to do. Agreement to date is only=20 > to change=20 > > From and To header field URIs in mid-dialog requests. > > Changing the To header field URI in a response would=20 > require separate=20 > > agreement. I suggest you write an I-D and try to get=20 > backing. However,=20 > > I fear you will encounter strong opposition. > >=20 > > Regards, > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > Sent: 04 May 2006 09:37 > > > To: Elwell, John; sip@ietf.org > > > Cc: chister.holmberg@ericsson.com; > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > esasaki@NTT-AT.COM > > > Subject: AW: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > > Dear John et all, > > > I'm sorry to go again into the opposite oppinion but I'm=20 > still in=20 > > > favour of enhancing the draft to provide identity in the=20 > To header=20 > > > field URI of a response. > > >=20 > > > I don't know if we have to rediscuss all the possibilities and=20 > > > assumptions. But fact is that such a to header change would > > be useful > > > for some services. > > >=20 > > > Best Regards > > >=20 > > > Roland > > >=20 > > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > An: sip@ietf.org > > > > Betreff: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > > > >=20 > > > >=20 > > > > There are three open issues in this draft and a fourth that > > > was raised > > > > subsequently. This mail initiates discussion on the first > > issue. I > > > > will initiate discussion on the other three issues in separate=20 > > > > mails. > > > >=20 > > > > Issue 1 appears in section 5 and concerns the fact that > > this draft > > > > intentionally does not address response identity, and > > therefore the > > > > identity of a dialog-forming responder to an INVITE request is=20 > > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > > direction rather than in the response to the INVITE=20 > request. The=20 > > > > open issue is stated as: > > > >=20 > > > > "OPEN ISSUE. Should this be extended to allow a > > URI in the To > > > > header field of a response to change compared with > > > the To header > > > > field in a request? This could convey a connected > > > identity in a > > > > response to an INVITE request, but it would not be=20 > > > > authenticated. > > > > Authentication would have to rely on transitive > > trust, which > > > > might > > > > be feasible in a closed environment where the sips > > > URI scheme is > > > > used." > > > >=20 > > > > There was considerable list discussion on this shortly after > > > > IETF65 with no > > > > resolution. I won't attempt to summarise it. My opinion > > > (for what it's > > > > worth) is as follows. > > > >=20 > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From header=20 > > > > field URIs throughout a dialog (i.e., it anticipates that > > these will > > > > be allowed to change mid-dialog), it says nothing to=20 > warn of any=20 > > > > future removal of the requirement that the To header=20 > field URI in=20 > > > > the response be the same as that in the request. > > Therefore I believe > > > > it would be dangerous to specify such a change to the To header = > > > > field URI. > > > >=20 > > > > 2. The prime motivation for this draft was to provide > > authenticated > > > > identity, i.e., to complement the sip-identity draft. An > > identity in > > > > the To header field of a response cannot be authenticated, for=20 > > > > reasons stated many times on this list and at meetings. > > Therefore, > > > > at least in the Internet, a response identity would have little = > > > > value. > > > >=20 > > > > 3. A comprehensive list of reasons for not going down > > that path were > > > > given by Jon Peterson (editor of the Identity draft) in a > > message to > > > > this list on 5th April. > > > >=20 > > > > 4. In closed environments an unauthenticated response > > identity might > > > > have some value. But this could be achieved using > > > P-Asserted-Identity, say, > > > > rather than bending the rules for To headers in responses. > > > >=20 > > > > Therefore I am NOT in favour of enhancing the draft to provide=20 > > > > identity in the To header field URI of a response. Can > > people agree > > > > to this resolution of the issue? > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: Internet-Drafts@ietf.org=20 > [mailto:Internet-Drafts@ietf.org] > > > > > Sent: 26 April 2006 20:50 > > > > > To: i-d-announce@ietf.org > > > > > Cc: sip@ietf.org > > > > > Subject: [Sip] I-D > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > >=20 > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > > directories. > > > > > This draft is a work item of the Session Initiation Protocol=20 > > > > > Working Group of the IETF. > > > > >=20 > > > > > Title : Connected Identity in the Session=20 > > > > > Initiation Protocol (SIP) > > > > > Author(s) : J. Elwell > > > > > Filename :=20 > > draft-ietf-sip-connected-identity-00.txt > > > > > Pages : 20 > > > > > Date : 2006-4-26 > > > > > =09 > > > > > Because of retargeting of a Session Initiation Protocol > > > > > (SIP) dialog- > > > > > forming request, the UAS can have a different identity > > > > from that in > > > > > the To header. This document provides a means for > > that 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 PSTN > > > > > behind a gateway. This document normatively updates RFC > > > > > 3261 (SIP). > > > > > This work is being discussed on the sip@ietf.org > > mailing list. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > A URL for this Internet-Draft is: > > > > > = http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > dentity-00.txt > > > > >=20 > > > > > To remove yourself from the I-D Announcement list, send a > > > > message to > > > > > i-d-announce-request@ietf.org with the word=20 > unsubscribe in the=20 > > > > > body of the message. > > > > > You can also visit > > > > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > > to change your subscription settings. > > > > >=20 > > > > >=20 > > > > > Internet-Drafts are also available by anonymous FTP.=20 > Login with=20 > > > > > the username "anonymous" and a password of your=20 > e-mail address. > > > > > After > > > logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-ietf-sip-connected-identity-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 > > > > >=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-ietf-sip-connected-identity-00.txt". > > > > > =09 > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility.=20 > > To use this > > > > > feature, insert the command "ENCODING mime"=20 > > 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. > > > > > =09 > > > > > =09 > > > > > Below is the data which will enable a MIME compliant > > mail reader > > > > > implementation to automatically retrieve the ASCII > > version of the > > > > > 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=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 sip-implementors@cs.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 May 05 03:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuvX-000726-VP; Fri, 05 May 2006 03:40:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuvU-00071B-KA for sip@ietf.org; Fri, 05 May 2006 03:40:36 -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 1FbuvU-0005rC-Ho for sip@ietf.org; Fri, 05 May 2006 03:40:36 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbunK-00087g-KU for sip@ietf.org; Fri, 05 May 2006 03:32:13 -0400 Received: (qmail 20664 invoked by uid 0); 5 May 2006 07:32:01 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 May 2006 07:32:01 -0000 Message-ID: <000c01c67015$ff52abf0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" , "Jesske, R" , References: <5EB80D22825EEE42872083AD5BFFB594017F0E87@esealmw113.eemea.ericsson.se> Subject: Re: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Fri, 5 May 2006 09:32:00 +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.2869 X-Spam-Score: -2.6 (--) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 RFC3261 Section 12.2.1.1: "[...] It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification." Jeroen ----- Original Message ----- From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" ; "Jesske, R" ; Cc: ; Sent: Friday, May 05, 2006 9:22 AM Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Hi, >Technically it might work, but RFC3261 neither gives permission to change >the To header field URI in a response nor hints at a future lifting of this >restriction. So, where does RFC3261 give permisson to change the To header field URI later in a request, then??? I thought the changing of the URI was something that THIS GROUP has agreed is to be allowed. Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 04 May 2006 21:55 > To: Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > > Hi, > > From the safeness point of view, I thought we already agreed (at least > I haven't heard any disagreement) that doing it would not be unsafe, > since the arguments that modifying the To and/or From header URI would > affect the transaction logic were not true. > > Regards, > > Christer > > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 4. toukokuuta 2006 13:39 > To: Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > Roland, > > Well, you would need to convince the community that this is a > worthwhile and safe thing to do. Agreement to date is only to change > From and To header field URIs in mid-dialog requests. > Changing the To header field URI in a response would require separate > agreement. I suggest you write an I-D and try to get backing. However, > I fear you will encounter strong opposition. > > Regards, > > John > > > -----Original Message----- > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > Sent: 04 May 2006 09:37 > > To: Elwell, John; sip@ietf.org > > Cc: chister.holmberg@ericsson.com; > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > esasaki@NTT-AT.COM > > Subject: AW: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > > > > Dear John et all, > > I'm sorry to go again into the opposite oppinion but I'm still in > > favour of enhancing the draft to provide identity in the To header > > field URI of a response. > > > > I don't know if we have to rediscuss all the possibilities and > > assumptions. But fact is that such a to header change would > be useful > > for some services. > > > > Best Regards > > > > Roland > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > An: sip@ietf.org > > > Betreff: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt > > > > > > > > > There are three open issues in this draft and a fourth that > > was raised > > > subsequently. This mail initiates discussion on the first > issue. I > > > will initiate discussion on the other three issues in separate > > > mails. > > > > > > Issue 1 appears in section 5 and concerns the fact that > this draft > > > intentionally does not address response identity, and > therefore the > > > identity of a dialog-forming responder to an INVITE request is > > > conveyed in a separate request (e.g., UPDATE) in the reverse > > > direction rather than in the response to the INVITE request. The > > > open issue is stated as: > > > > > > "OPEN ISSUE. Should this be extended to allow a > URI in the To > > > header field of a response to change compared with > > the To header > > > field in a request? This could convey a connected > > identity in a > > > response to an INVITE request, but it would not be > > > authenticated. > > > Authentication would have to rely on transitive > trust, which > > > might > > > be feasible in a closed environment where the sips > > URI scheme is > > > used." > > > > > > There was considerable list discussion on this shortly after > > > IETF65 with no > > > resolution. I won't attempt to summarise it. My opinion > > (for what it's > > > worth) is as follows. > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header > > > field URIs throughout a dialog (i.e., it anticipates that > these will > > > be allowed to change mid-dialog), it says nothing to warn of any > > > future removal of the requirement that the To header field URI in > > > the response be the same as that in the request. > Therefore I believe > > > it would be dangerous to specify such a change to the To header > > > field URI. > > > > > > 2. The prime motivation for this draft was to provide > authenticated > > > identity, i.e., to complement the sip-identity draft. An > identity in > > > the To header field of a response cannot be authenticated, for > > > reasons stated many times on this list and at meetings. > Therefore, > > > at least in the Internet, a response identity would have little > > > value. > > > > > > 3. A comprehensive list of reasons for not going down > that path were > > > given by Jon Peterson (editor of the Identity draft) in a > message to > > > this list on 5th April. > > > > > > 4. In closed environments an unauthenticated response > identity might > > > have some value. But this could be achieved using > > P-Asserted-Identity, say, > > > rather than bending the rules for To headers in responses. > > > > > > Therefore I am NOT in favour of enhancing the draft to provide > > > identity in the To header field URI of a response. Can > people agree > > > to this resolution of the issue? > > > > > > John > > > > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: 26 April 2006 20:50 > > > > To: i-d-announce@ietf.org > > > > Cc: sip@ietf.org > > > > Subject: [Sip] I-D > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > > directories. > > > > This draft is a work item of the Session Initiation Protocol > > > > Working Group of the IETF. > > > > > > > > Title : Connected Identity in the Session > > > > Initiation Protocol (SIP) > > > > Author(s) : J. Elwell > > > > Filename : > draft-ietf-sip-connected-identity-00.txt > > > > Pages : 20 > > > > Date : 2006-4-26 > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > (SIP) dialog- > > > > forming request, the UAS can have a different identity > > > from that in > > > > the To header. This document provides a means for > that 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 PSTN > > > > behind a gateway. This document normatively updates RFC > > > > 3261 (SIP). > > > > This work is being discussed on the sip@ietf.org > mailing list. > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > dentity-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-connected-identity-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-connected-identity-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 > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 04:03:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbvFQ-00087R-Bf; Fri, 05 May 2006 04:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbvCh-000631-5l for sip@ietf.org; Fri, 05 May 2006 03:58: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 1Fbv7T-0006H5-Qk for sip@ietf.org; Fri, 05 May 2006 03:53:01 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYS00F018L23S@siemenscomms.co.uk> for sip@ietf.org; Fri, 05 May 2006 08:53:26 +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 <0IYS00E878L21W@siemenscomms.co.uk>; Fri, 05 May 2006 08:53:26 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Fri, 05 May 2006 08:52:58 +0100 Content-return: allowed Date: Fri, 05 May 2006 08:52:57 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Christer Holmberg (JO/LMF)" , Jeroen van Bemmel , "Jesske, R" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D3E40E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Christer, You are correct that it does not necessarily prevent us changing the = URI in a response in a "subsequent revision", but that is a different discus= sion =66rom the discussion we have already had and concluded on mid-dialog requests. As I said before to Roland, if there is interest in doing t= his it should be addressed in a separate I-D giving the background, requirem= ents, mechanism, etc. John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 05 May 2006 08:39 > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.= txt >=20 >=20 > Hi,=20 >=20 > >RFC3261 Section 12.2.1.1: "[...] It is expected that=20 > mandatory reflection of the original To and From URI in=20 > mid-dialog requests will be deprecated in a=20 > >subsequent revision of this specification." >=20 > Ok, I appologize for missing that. >=20 > However, that doesn't prevent us from also allowing to change=20 > the URI in responses in a "subsequence revision". >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Elwell, John" ; "Jesske, R"=20 > ; > Cc: ; > Sent: Friday, May 05, 2006 9:22 AM > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.= txt >=20 >=20 >=20 > Hi, >=20 > >Technically it might work, but RFC3261 neither gives=20 > permission to change=20 > >the To header field URI in a response nor hints at a future=20 > lifting of this > >restriction. >=20 > So, where does RFC3261 give permisson to change the To header=20 > field URI=20 > later in a request, then??? >=20 > I thought the changing of the URI was something that THIS=20 > GROUP has agreed=20 > is to be allowed. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 04 May 2006 21:55 > > To: Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > > > > > > Hi, > > > > From the safeness point of view, I thought we already=20 > agreed (at least > > I haven't heard any disagreement) that doing it would not be unsa= fe, > > since the arguments that modifying the To and/or From=20 > header URI would > > affect the transaction logic were not true. > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 4. toukokuuta 2006 13:39 > > To: Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > > > > Roland, > > > > Well, you would need to convince the community that this is a > > worthwhile and safe thing to do. Agreement to date is only to cha= nge > > From and To header field URIs in mid-dialog requests. > > Changing the To header field URI in a response would=20 > require separate > > agreement. I suggest you write an I-D and try to get=20 > backing. However, > > I fear you will encounter strong opposition. > > > > Regards, > > > > John > > > > > -----Original Message----- > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > Sent: 04 May 2006 09:37 > > > To: Elwell, John; sip@ietf.org > > > Cc: chister.holmberg@ericsson.com; > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > esasaki@NTT-AT.COM > > > Subject: AW: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > Dear John et all, > > > I'm sorry to go again into the opposite oppinion but I'm still = in > > > favour of enhancing the draft to provide identity in the To hea= der > > > field URI of a response. > > > > > > I don't know if we have to rediscuss all the possibilities and > > > assumptions. But fact is that such a to header change would > > be useful > > > for some services. > > > > > > Best Regards > > > > > > Roland > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > An: sip@ietf.org > > > > Betreff: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > was raised > > > > subsequently. This mail initiates discussion on the first > > issue. I > > > > will initiate discussion on the other three issues in separat= e > > > > mails. > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > this draft > > > > intentionally does not address response identity, and > > therefore the > > > > identity of a dialog-forming responder to an INVITE request i= s > > > > conveyed in a separate request (e.g., UPDATE) in the reverse > > > > direction rather than in the response to the INVITE request. = The > > > > open issue is stated as: > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > URI in the To > > > > header field of a response to change compared with > > > the To header > > > > field in a request? This could convey a connected > > > identity in a > > > > response to an INVITE request, but it would not be > > > > authenticated. > > > > Authentication would have to rely on transitive > > trust, which > > > > might > > > > be feasible in a closed environment where the sips > > > URI scheme is > > > > used." > > > > > > > > There was considerable list discussion on this shortly after > > > > IETF65 with no > > > > resolution. I won't attempt to summarise it. My opinion > > > (for what it's > > > > worth) is as follows. > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From hea= der > > > > field URIs throughout a dialog (i.e., it anticipates that > > these will > > > > be allowed to change mid-dialog), it says nothing to warn of = any > > > > future removal of the requirement that the To header=20 > field URI in > > > > the response be the same as that in the request. > > Therefore I believe > > > > it would be dangerous to specify such a change to the To head= er > > > > field URI. > > > > > > > > 2. The prime motivation for this draft was to provide > > authenticated > > > > identity, i.e., to complement the sip-identity draft. An > > identity in > > > > the To header field of a response cannot be authenticated, fo= r > > > > reasons stated many times on this list and at meetings. > > Therefore, > > > > at least in the Internet, a response identity would have litt= le > > > > value. > > > > > > > > 3. A comprehensive list of reasons for not going down > > that path were > > > > given by Jon Peterson (editor of the Identity draft) in a > > message to > > > > this list on 5th April. > > > > > > > > 4. In closed environments an unauthenticated response > > identity might > > > > have some value. But this could be achieved using > > > P-Asserted-Identity, say, > > > > rather than bending the rules for To headers in responses. > > > > > > > > Therefore I am NOT in favour of enhancing the draft to provid= e > > > > identity in the To header field URI of a response. Can > > people agree > > > > to this resolution of the issue? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Internet-Drafts@ietf.org=20 > [mailto:Internet-Drafts@ietf.org] > > > > > Sent: 26 April 2006 20:50 > > > > > To: i-d-announce@ietf.org > > > > > Cc: sip@ietf.org > > > > > Subject: [Sip] I-D > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > > directories. > > > > > This draft is a work item of the Session Initiation Protoco= l > > > > > Working Group of the IETF. > > > > > > > > > > Title : Connected Identity in the Session > > > > > Initiation Protocol (SIP) > > > > > Author(s) : J. Elwell > > > > > Filename : > > draft-ietf-sip-connected-identity-00.txt > > > > > Pages : 20 > > > > > Date : 2006-4-26 > > > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > > (SIP) dialog- > > > > > forming request, the UAS can have a different identity > > > > from that in > > > > > the To header. This document provides a means for > > that 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 PSTN > > > > > behind a gateway. This document normatively updates RFC > > > > > 3261 (SIP). > > > > > This work is being discussed on the sip@ietf.org > > mailing list. > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connecte= d-i > > > > > dentity-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.=20 > Login with > > > > > the username "anonymous" and a password of your=20 > e-mail address. > > > > > After > > > logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-ietf-sip-connected-identity-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-connected-identity-00.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document i= n > > > > > 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=20 > current sip Use > > > > sipping@ietf.org for new developments on the application of s= ip > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip= =20 >=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 May 05 09:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc06q-0005nk-3m; Fri, 05 May 2006 09:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc06o-0005nc-5G; Fri, 05 May 2006 09:12:38 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc06k-0003VX-KV; Fri, 05 May 2006 09:12:38 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k45DCXOO019096; Fri, 5 May 2006 15:12:33 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k45DCXO5023497; Fri, 5 May 2006 15:12:33 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 15:12:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 15:12:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What happened to all the good ideas? Thread-Index: AcZvvqPKMhNWEeiJQu+FZ1bvgonacA== From: "Tschofenig, Hannes" To: , "Sipping" X-OriginalArrivalTime: 05 May 2006 13:12:33.0498 (UTC) FILETIME=[923A33A0:01C67045] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Sip] What happened to all the good ideas? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all,=20 before the IETF#65 meeting a long and interesting discussion was triggered by Dean's message entitled as "Principle of Dividing and Conquering" (see http://www1.ietf.org/mail-archive/web/sip/current/msg12997.html). Many suggestions were made and also the idea of (somehow) finding more document reviewers was repeately mentioned (as an alternative to just beating the document authors/editors). Sure, these discussions happened before the IETF meeting were everyone is excited about getting things done.=20 So, what happened to the idea of early reviews? I could suggest some documents for review :-) 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 Fri May 05 10:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1AL-0001uh-9k; Fri, 05 May 2006 10:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1AK-0001uc-ND for sip@ietf.org; Fri, 05 May 2006 10:20:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1AI-0005uw-DS for sip@ietf.org; Fri, 05 May 2006 10:20:20 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 May 2006 10:20:18 -0400 X-IronPort-AV: i="4.05,93,1146456000"; d="scan'208"; a="87962618:sNHT29195104" 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 k45EKIvF014687; Fri, 5 May 2006 10:20:18 -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.211); Fri, 5 May 2006 10:20:17 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 10:20:17 -0400 Message-ID: <445B5F21.90909@cisco.com> Date: Fri, 05 May 2006 10:20:17 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "jdrosen >> Joseph Drommer" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 14:20:17.0843 (UTC) FILETIME=[08C40830:01C6704F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP IETF Subject: [Sip] draft-rosenberg-sip-route-construct-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 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. 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. 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. I like the use of the lr parameter in a contact to decide whether to rewrite the aor with the registered contact. clever. 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. 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. 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 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. 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 May 05 12:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc2k2-00087n-0J; Fri, 05 May 2006 12:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc2k0-00087f-7Y for sip@ietf.org; Fri, 05 May 2006 12:01:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc2k0-0001w6-5v for sip@ietf.org; Fri, 05 May 2006 12:01:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fc2ab-0004Zz-Hv for sip@ietf.org; Fri, 05 May 2006 11:51:36 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 May 2006 08:51:33 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="1801982710:sNHT28378168" 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 k45FpBYs015765 for ; Fri, 5 May 2006 08:51:32 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 08:51:16 -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: Fri, 5 May 2006 08:51:00 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB01811811@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Refer 3515 has a minor inconsistency thread-index: AcZwTy2/uxgQNCVgRYS0yoQz9FUA0AAC6Wgg From: "Arunachalam Venkatraman \(arunvenk\)" To: "SIP IETF" X-OriginalArrivalTime: 05 May 2006 15:51:16.0067 (UTC) FILETIME=[BE1EEB30:01C6705B] X-Spam-Score: -2.6 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Refer 3515 has a minor inconsistency X-BeenThere: sip@ietf.org X-Mailman-Version: 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.4.6 Multiple REFER Requests in a Dialog A REFER creates an implicit subscription sharing the dialog identifiers in the REFER request. If more than one REFER is issued in the same dialog (a second attempt at transferring a call for example), the dialog identifiers do not provide enough information to associate the resulting NOTIFYs with the proper REFER. Thus, for the second and subsequent REFER requests a UA receives in a given dialog, it MUST include an id parameter[2] in the Event header field of each NOTIFY containing the sequence number (the number from the CSeq header field value) of the REFER this NOTIFY is associated with. This id parameter MAY be included in NOTIFYs to the first REFER a UA receives in a given dialog. A SUBSCRIBE sent to refresh or terminate this subscription MUST contain this id parameter. The last two paragraphs lead to the following conclusion - The first REFER subscription in a dialog cannot be refreshed if the transferee does not send an id in the INITIAL notify. This does not seem reasonable and so I think the qualification "second and subsequent" above must be replaced with "all". It is a minor point and an unlikely use case. It could be logged as such. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 12:43:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3MR-0006Vf-Dn; Fri, 05 May 2006 12:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3MQ-0006VX-8c for sip@ietf.org; Fri, 05 May 2006 12:40:58 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3MN-0003OZ-Tw for sip@ietf.org; Fri, 05 May 2006 12:40:58 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k45Gegfn009797; Fri, 5 May 2006 10:40:43 -0600 (MDT) 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: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Fri, 5 May 2006 10:40:42 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcY5j29dKQxxIed4SCWenzWDWU3cwgCDbzWgAWHdczABPKwkYAAB1NDAAC8iRbAEU4MgYwAjT98AAAWt1EUAICbuYAW3rKgQ From: "Jean-Francois Mule" To: "Michael Procter" , "Cullen Jennings" , "Kevin Lingle (klingle)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Ok, so I'm not sure what this thread concluded as far as the original comment on the current mib text for allowing/disallowing 3rd-party registration. My preference and proposal for the mib module would be to: a) keep it simple: one on/off control object for allowing 3rd-party reg (no refinements based on the two types of 3rd-party reg) b) make the mib text for what 3rd-party reg is more general to include both known types of 3rd-party registration: To !=3D From, and, To !=3D source of the REGISTER message is coming from Does this sound reasonable to close the comment? Jean-Francois > -----Original Message----- > From: Michael Procter [mailto:michael.procter@citel.com] > Sent: Thursday, April 06, 2006 2:58 AM > To: Cullen Jennings; Jean-Francois Mule; Kevin Lingle (klingle); > sip@ietf.org > Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder > Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip- > mib comments) >=20 > Cullen Jennings wrote: > > This is way off track of anything to do with the MIB but ... >=20 > Indeed. I'd like to try to bring it back to the topic, by referring > to the original question that was posed. At least we all have more > background to it now! >=20 > > > Cullen Jennings wrote: > > >> sipRegAlloowThirdParty - there are two definitions in common > > >> usage for 3rd party reg. This is one of them. >=20 > Looking again at the definition in the MIB draft, I am confused: >=20 > DESCRIPTION > "This object reflects whether or not the Registrar > SHOULD allow third party registrations. In third-party > registration, the entity issuing the request (in the > From header) is different from the entity being > registered (in the To header) to whom the provided > Contact information applies. >=20 > I first read this as describing the From !=3D To case, but looking > again, I can see how it might be read as the Contact !=3D source case. > The phrase that I find confusing is 'entity being registered (in > the To header) to whom the provided Contact information applies'. >=20 > This phrase always applies, since the main function of a REGISTER > message is to provide a Contact that applies to the AoR in the To > header. >=20 > Is this clause supposed to identify the 'Contact does not correspond > to the source of the REGISTER message' case? >=20 > > >> However, I don't know of any > > >> deployment situations that allow this type of 3rd party reg. >=20 > I know of deployments of 3rd party registrations (of the To !=3D From > type). I am no longer sure whether this is the same type as > defined in the MIB draft or not! >=20 > Whether either or both approaches need MIB support is for more > MIB-minded people than me to contemplate. I was just trying to > clarify whether or not certain types of deployment exist. >=20 > Regards, >=20 > Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 05 17:02:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7PQ-00067M-7g; Fri, 05 May 2006 17:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc7PO-00067H-VS for sip@ietf.org; Fri, 05 May 2006 17:00:18 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc7PO-0001Rn-LX for sip@ietf.org; Fri, 05 May 2006 17:00:18 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k45L1GN4026447 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 5 May 2006 16:01:17 -0500 In-Reply-To: <445B5F21.90909@cisco.com> References: <445B5F21.90909@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6290D568-9F19-4CAE-9F1B-40BD19FBEE63@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 Date: Fri, 5 May 2006 16:00:13 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 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 From sip-bounces@ietf.org Fri May 05 20:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcACd-0000Es-WA; Fri, 05 May 2006 19:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcACc-0000Em-KI for sip@ietf.org; Fri, 05 May 2006 19:59:18 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcACb-0000AF-82 for sip@ietf.org; Fri, 05 May 2006 19:59:18 -0400 Received: (qmail 30983 invoked by uid 0); 5 May 2006 23:59:14 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 May 2006 23:59:14 -0000 Message-ID: <000801c6709f$e83c1340$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "jdrosen >> Joseph Drommer" References: <445B5F21.90909@cisco.com> Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 Date: Sat, 6 May 2006 01:59:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 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 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: 1. Each compliant proxy adds a new 'rt' flag to its Via header 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 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 Another alternative would be for the proxy/UAS that sends the 305 to remove all rt flags starting from the top, except the last of a continuous series. A proxy would then recurse on 305 iff it finds the 'rt' flag still in its Via header. For your example: REGISTER via: p-3;tr via: p-2;tr via: p-1 <-- does not support it via: uac p-4 would formulate: 305 Use Proxy via: p-3 <-- removed via: p-2;tr via: p-1 <-- still does not support it via: uac p-2 would receive: 305 Use Proxy via: p-2;tr <-- set, implies recurse via: p-1 <-- still does not support it via: uac This avoids the overhead of adding headers to all requests (and to 305 responses) 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 Sat May 06 07:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcKYk-0001zO-JD; Sat, 06 May 2006 07:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcKYi-0001z0-KU for sip@ietf.org; Sat, 06 May 2006 07:02:48 -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 1FcKYi-0001xR-J1 for sip@ietf.org; Sat, 06 May 2006 07:02:48 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FcKSQ-0006os-50 for sip@ietf.org; Sat, 06 May 2006 06:56:20 -0400 Received: (qmail 13298 invoked by uid 0); 6 May 2006 10:56:15 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 May 2006 10:56:15 -0000 Message-ID: <001e01c670fb$b03c93a0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" , "jdrosen >> Joseph Drommer" References: <445B5F21.90909@cisco.com> <000801c6709f$e83c1340$31713b51@BEMBUSTER> Subject: Re: [Sip] draft-rosenberg-sip-route-construct-01 Date: Sat, 6 May 2006 12:56:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.6 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 > 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 > Better yet: instead of removing the 'rt' flag, the proxy would simply recurse regardless of the Redirect-Target count (A) or presence of the 'tr' flag (solution B below). No need to modify the request to implement this policy In addition, I think we would need the following mechanism: proxy P-3 in your example adds a new header containing the current value of Max-Forwards found in the request. The element recursing on the 305 must then set its Max-Forwards to this value - 1, to avoid infinite loops in case of bad configuration (i.e. proxies playing ping-pong) Regards, Jeroen > Another alternative would be for the proxy/UAS that sends the 305 to > remove all rt flags starting from the top, except the last of a continuous > series. A proxy would then recurse on 305 iff it finds the 'rt' flag still > in its Via header. > > For your example: > REGISTER > via: p-3;tr > via: p-2;tr > via: p-1 <-- does not support it > via: uac > > p-4 would formulate: > 305 Use Proxy > via: p-3 <-- removed > via: p-2;tr > via: p-1 <-- still does not support it > via: uac > > p-2 would receive: > 305 Use Proxy > via: p-2;tr <-- set, implies recurse > via: p-1 <-- still does not support it > via: uac > > This avoids the overhead of adding headers to all requests (and to 305 > responses) > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 06 14:59:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcRxc-0005T2-A9; Sat, 06 May 2006 14:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcRxb-0005Sx-1A for sip@ietf.org; Sat, 06 May 2006 14:56:59 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcRxZ-0004Qc-8V for sip@ietf.org; Sat, 06 May 2006 14:56:59 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 9A40F1400AA; Sat, 6 May 2006 21:56:46 +0300 (EEST) Received: from rautu (in-vitro246.gprs.dnafinland.fi [62.78.121.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 3538E13F977; Sat, 6 May 2006 21:56:35 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3A2DEF0173; Sat, 6 May 2006 21:56:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17500.61784.185527.783328@rautu.tutpro.com> Date: Sat, 6 May 2006 21:56:24 +0300 From: Juha Heinanen To: Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 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 Erkki.Koivusalo@nokia.com writes: > - If the operator wants to use a single set of servers both > for load balancing and backup, then only single SRV record > would be introduced. In this case the UA should set up its > primary and backup connection towards two different proxies > within this single record. UA would only do so if it does not > find SRV records for SIP Outbound with higher Priority value. if i understood correctly, this option is what i prefer, i.e., a single pool of outbound proxies with equal priority value. the notion of primary and backup should be abolished from outbound i-d if it still is there. -- 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 Sun May 07 05:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcfJ6-0005MW-Tx; Sun, 07 May 2006 05:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcfJ6-0005Lx-FF for sip@ietf.org; Sun, 07 May 2006 05:12:04 -0400 Received: from bzq-114-71-192.cust.bezeqint.net ([192.114.71.192] helo=calllan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcfEn-0006IO-7l for sip@ietf.org; Sun, 07 May 2006 05:07:39 -0400 Received: from yonicomp ([88.153.112.56]) by calllan.com (calllan.com [192.114.71.192]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 34-md50000000021.tmp for ; Sun, 07 May 2006 12:11:26 +0200 From: "Yonatan Doron" To: "'Paul Kyzivat'" Subject: RE: [Sip] SIP Call Hold reply Date: Sun, 7 May 2006 12:05:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZv1Yzx9sJMosW9SgypDJYCEdWE1wB542yA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <445A842D.3040600@cisco.com> X-Spam-Processed: calllan.com, Sun, 07 May 2006 12:11:26 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 88.153.112.56 X-Return-Path: yoni@usbphone.com X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Thanks for your reply. But still, whether I use the old or new method to request a hold: how can I, as the hold requester, determine from the reply whether the recipient has agreed or not to the hold request? RFC 2543 doesn't mention how the recipient should reply to a hold request. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, May 05, 2006 12:46 AM To: Yonatan Doron Cc: sip@ietf.org Subject: Re: [Sip] SIP Call Hold reply The behavior you describe is non-conforming to 3264. So the UA is probably only compliant to 2543, or something interim between 2543 and 3261. The best recovery action in this case is to fall back to the 2543 hold mechanism - send an offer with c=0.0.0.0. Paul Yonatan Doron wrote: > According to my understanding, a UA which receives a request for > call-hold ( an INVITE with SDP containing the media field "sendonly"), > may accept the hold by sending a 200OK reply containing the SDP media > field "recvonly". > The problem is that the SIP clients I have tried, all answer a hold > request with a "sendrecv" field, which actually means that they > *reject* the request for hold (they do not agree to only receive the stream). > > If this is true, how can my client support this backward behaviour ? > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 07 14:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fco8W-0008JH-EH; Sun, 07 May 2006 14:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fco8U-0008JB-IC for sip@ietf.org; Sun, 07 May 2006 14:37:42 -0400 Received: from smtp.ycn.com ([212.88.160.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fco8T-0001yt-8x for sip@ietf.org; Sun, 07 May 2006 14:37:42 -0400 Received: from notebook (85-90-133-128.DSL.ycn.com [85.90.133.128]) by smtp.ycn.com (Postfix) with ESMTP id 77A42A6048; Sun, 7 May 2006 20:37:25 +0200 (CEST) From: "Franz Edler" To: "'Yonatan Doron'" Subject: AW: [Sip] SIP Call Hold reply Date: Sun, 7 May 2006 20:37:31 +0200 Message-ID: <003101c67205$4c956560$0600a8c0@notebook> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZv1Yzx9sJMosW9SgypDJYCEdWE1wB542yAABGi+WA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: 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 > Thanks for your reply. > But still, whether I use the old or new method to request a hold: how can > I, > as the hold requester, determine from the reply whether the recipient has > agreed or not to the hold request? > RFC 2543 doesn't mention how the recipient should reply to a hold request. I agree that's definitely not possible. But maybe it does not hurt very much. Normally in the case of hold some "music on hold" is rendered. This should be an additional sign to the session partner that the media stream he sends is not recognized. And BTW, how many old (RFC 2543 based) User Agents are still around? Franz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 07 16:09:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcpWQ-0000vX-7h; Sun, 07 May 2006 16:06:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcpWO-0000vM-Pq for sip@ietf.org; Sun, 07 May 2006 16:06: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 1FcpWO-0006mM-Np for sip@ietf.org; Sun, 07 May 2006 16:06:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FcpT7-0002y1-K2 for sip@ietf.org; Sun, 07 May 2006 16:03:06 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 07 May 2006 13:03:05 -0700 X-IronPort-AV: i="4.05,99,1146466800"; d="scan'208"; a="1802369142:sNHT33548728" Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k47K34Yg005168; Sun, 7 May 2006 13:03:04 -0700 (PDT) Received: from [192.168.1.2] ([10.21.98.168]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 May 2006 13:03:03 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FCADCE2-4FD0-4C13-A51E-5281A22A521D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Sun, 7 May 2006 10:48:37 -0700 To: Jean-Francois Mule X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 07 May 2006 20:03:03.0813 (UTC) FILETIME=[3FDD8350:01C67211] X-Spam-Score: -2.3 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Michael Procter , "Kevin Lingle \(klingle\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How about update the description to be 100% clear what type it is. I really think we only need to deal with the type defined in RFC 3261 - future things could do more. I think the current description is the type defined in 3261. The text below might works as an update but perhaps someone has better text. Old >> DESCRIPTION >> "This object reflects whether or not the Registrar >> SHOULD allow third party registrations. In third-party >> registration, the entity issuing the request (in the >> From header) is different from the entity being >> registered (in the To header) to whom the provided >> Contact information applies. New >> DESCRIPTION >> "This object reflects whether or not the Registrar >> SHOULD allow third party registrations as defined in >> Section 10.2 of RFC 3261. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> In third-party >> registration, the entity issuing the request (in the >> From header) is different from the entity being >> registered (in the To header) to whom the provided >> Contact information applies. PS - From an AD point of view, I am OK with no change on this. I think it is relatively clear that it is the To From type and this is the only type defined in 3261 so I think it will be ok. On May 5, 2006, at 9:40 AM, Jean-Francois Mule wrote: > All, > > Ok, so I'm not sure what this thread concluded as far as the > original > comment on the current mib text for allowing/disallowing 3rd-party > registration. > > My preference and proposal for the mib module would be to: > a) keep it simple: one on/off control object for allowing 3rd-party > reg > (no refinements based on the two types of 3rd-party reg) > b) make the mib text for what 3rd-party reg is more general to include > both known types of 3rd-party registration: To != From, and, To != > source of the REGISTER message is coming from > > Does this sound reasonable to close the comment? > > Jean-Francois > >> -----Original Message----- >> From: Michael Procter [mailto:michael.procter@citel.com] >> Sent: Thursday, April 06, 2006 2:58 AM >> To: Cullen Jennings; Jean-Francois Mule; Kevin Lingle (klingle); >> sip@ietf.org >> Cc: Romascanu, Dan (Dan); Juergen Schoenwaelder >> Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip- >> mib comments) >> >> Cullen Jennings wrote: >>> This is way off track of anything to do with the MIB but ... >> >> Indeed. I'd like to try to bring it back to the topic, by referring >> to the original question that was posed. At least we all have more >> background to it now! >> >>>> Cullen Jennings wrote: >>>>> sipRegAlloowThirdParty - there are two definitions in common >>>>> usage for 3rd party reg. This is one of them. >> >> Looking again at the definition in the MIB draft, I am confused: >> >> DESCRIPTION >> "This object reflects whether or not the Registrar >> SHOULD allow third party registrations. In third-party >> registration, the entity issuing the request (in the >> From header) is different from the entity being >> registered (in the To header) to whom the provided >> Contact information applies. >> >> I first read this as describing the From != To case, but looking >> again, I can see how it might be read as the Contact != source case. >> The phrase that I find confusing is 'entity being registered (in >> the To header) to whom the provided Contact information applies'. >> >> This phrase always applies, since the main function of a REGISTER >> message is to provide a Contact that applies to the AoR in the To >> header. >> >> Is this clause supposed to identify the 'Contact does not correspond >> to the source of the REGISTER message' case? >> >>>>> However, I don't know of any >>>>> deployment situations that allow this type of 3rd party reg. >> >> I know of deployments of 3rd party registrations (of the To != From >> type). I am no longer sure whether this is the same type as >> defined in the MIB draft or not! >> >> Whether either or both approaches need MIB support is for more >> MIB-minded people than me to contemplate. I was just trying to >> clarify whether or not certain types of deployment exist. >> >> Regards, >> >> Michael Procter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 07 16:37:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcpyC-0003on-R7; Sun, 07 May 2006 16:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcpyB-0003oi-GJ for sip@ietf.org; Sun, 07 May 2006 16:35:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcpWO-0006m2-Sp for sip@ietf.org; Sun, 07 May 2006 16:06:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FcpS9-0002xH-Bn for sip@ietf.org; Sun, 07 May 2006 16:02:07 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 May 2006 13:02:05 -0700 X-IronPort-AV: i="4.05,99,1146466800"; d="scan'208"; a="1802368932:sNHT30270154" Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k47K24VI026512; Sun, 7 May 2006 13:02:04 -0700 (PDT) Received: from [192.168.1.2] ([10.21.98.168]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 7 May 2006 13:02:04 -0700 In-Reply-To: <739E02BA-E514-436C-A12B-FD1B7AEC8DA0@softarmor.com> References: <739E02BA-E514-436C-A12B-FD1B7AEC8DA0@softarmor.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt Date: Sun, 7 May 2006 07:43:55 -0700 To: Robert Sparks , Alan Hawrylyshen , Scott Lawrence X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 07 May 2006 20:02:04.0406 (UTC) FILETIME=[1C74B960:01C67211] X-Spam-Score: -2.3 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Nice to see this document happening - thanks. This document is updating 3261, at a high level it should fix the problem we identified which is a few fold, 1) loop detection is not optional 2) the description in 2361 has a bug (with via) 3) the description seem to be hard for implementers to get right. This document should fix those - all of them. I think this document should mention the bug fix to 3261. If implementers are having a hard time getting 3261 implementation correct, could we provide some advice that made it easier to implement? I agree it is confusing in 3261 but the basic idea is pretty simple. The security section is pretty weak here - might be nice to you can only do this attack if you have an account on the service and can register bad contacts that create the loop and that if it happened on todays networks how one can trace it to the user that did it. Cullen On Apr 10, 2006, at 1:15 PM, Dean Willis wrote: > > I'd like to ask the working group to review the "forking loop fix" > draft preparatory to requesting publication of it as a standards- > track RFC. > > > The document revised following the Dallas meeting document is > available from: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-fork-loop- > fix-01.txt > > > > I'd like to complete this review by May 7, 2006. > > Please send all comments to the list and copy the author, > rjs@estacado.net > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 08 04:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1EK-0006R2-UO; Mon, 08 May 2006 04:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1EJ-0006Qx-Bp for sip@ietf.org; Mon, 08 May 2006 04:36:35 -0400 Received: from bzq-114-71-192.cust.bezeqint.net ([192.114.71.192] helo=calllan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd1EI-00074W-1L for sip@ietf.org; Mon, 08 May 2006 04:36:35 -0400 Received: from yonicomp (bzq-88-153-112-56.red.bezeqint.net [88.153.112.56]) by calllan.com (calllan.com [192.114.71.192]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 23-md50000000022.tmp for ; Mon, 08 May 2006 11:40:31 +0200 From: "Yonatan Doron" To: "'Franz Edler'" Subject: RE: [Sip] SIP Call Hold reply Date: Mon, 8 May 2006 11:34:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZv1Yzx9sJMosW9SgypDJYCEdWE1wB542yAABGi+WAAH2k9oA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <003101c67205$4c956560$0600a8c0@notebook> X-Spam-Processed: calllan.com, Mon, 08 May 2006 11:40:31 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 88.153.112.56 X-Return-Path: yoni@usbphone.com X-MDaemon-Deliver-To: sip@ietf.org 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 Message-Id: Actually, I am currently working with a bit old version of eyeBeam (version 3013), and the latest version of Express Talk. Both answer a hold request according to the old RFC. Can you recommend of any good free SIP clients out there which comply to the latest RFC ? Thanks. -----Original Message----- From: Franz Edler [mailto:franz.edler@ycn.com] Sent: Sunday, May 07, 2006 8:38 PM To: 'Yonatan Doron' Cc: sip@ietf.org Subject: AW: [Sip] SIP Call Hold reply > Thanks for your reply. > But still, whether I use the old or new method to request a hold: how > can I, as the hold requester, determine from the reply whether the > recipient has agreed or not to the hold request? > RFC 2543 doesn't mention how the recipient should reply to a hold request. I agree that's definitely not possible. But maybe it does not hurt very much. Normally in the case of hold some "music on hold" is rendered. This should be an additional sign to the session partner that the media stream he sends is not recognized. And BTW, how many old (RFC 2543 based) User Agents are still around? Franz _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 05:05:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1dx-0006WD-Ui; Mon, 08 May 2006 05:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1dw-0006No-QX for sip@ietf.org; Mon, 08 May 2006 05:03:04 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd1ds-0008AI-Ea for sip@ietf.org; Mon, 08 May 2006 05:03:04 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k488tJCr007773; Mon, 8 May 2006 02:55:20 -0600 (MDT) 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: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Mon, 8 May 2006 02:55:18 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcZyEUKjfuNdVmKzS7quG1MRC+xqUQAaRw/g From: "Jean-Francois Mule" To: "Cullen Jennings" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Michael Procter , "Kevin Lingle \(klingle\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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, works for me. We will just add a citation to RFC3261 in the object description to make it clearer (we will also keep the existing REFERENCE clause for that object). Jean-Francois. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, May 07, 2006 11:49 AM > To: Jean-Francois Mule > Cc: Michael Procter; Kevin Lingle (klingle); sip@ietf.org; Romascanu, > Dan (Dan); Juergen Schoenwaelder > Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip- > mib comments) >=20 >=20 > How about update the description to be 100% clear what type it is. I > really think we only need to deal with the type defined in RFC 3261 - > future things could do more. I think the current description is the > type defined in 3261. The text below might works as an update but > perhaps someone has better text. >=20 > Old > >> DESCRIPTION > >> "This object reflects whether or not the Registrar > >> SHOULD allow third party registrations. In third-party > >> registration, the entity issuing the request (in the > >> From header) is different from the entity being > >> registered (in the To header) to whom the provided > >> Contact information applies. >=20 > New > >> DESCRIPTION > >> "This object reflects whether or not the Registrar > >> SHOULD allow third party registrations as defined in > >> Section 10.2 of RFC 3261. >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > >> In third-party > >> registration, the entity issuing the request (in the > >> From header) is different from the entity being > >> registered (in the To header) to whom the provided > >> Contact information applies. >=20 > PS - From an AD point of view, I am OK with no change on this. I > think it is relatively clear that it is the To From type and this is > the only type defined in 3261 so I think it will be 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 Mon May 08 05:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1fY-0007ap-LI; Mon, 08 May 2006 05:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1fX-0007ak-Jr for sip@ietf.org; Mon, 08 May 2006 05:04:43 -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 1Fd1fX-0008Bn-IO for sip@ietf.org; Mon, 08 May 2006 05:04:43 -0400 Received: from smtp.ycn.com ([212.88.160.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd1dN-0003fV-BX for sip@ietf.org; Mon, 08 May 2006 05:02:30 -0400 Received: from notebook (85-90-133-128.DSL.ycn.com [85.90.133.128]) by smtp.ycn.com (Postfix) with ESMTP id 007BBA6079; Mon, 8 May 2006 11:02:25 +0200 (CEST) From: "Franz Edler" To: "'Yonatan Doron'" Subject: AW: [Sip] SIP Call Hold reply Date: Mon, 8 May 2006 11:02:28 +0200 Message-ID: <000d01c6727e$223f0900$0600a8c0@notebook> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcZv1Yzx9sJMosW9SgypDJYCEdWE1wB542yAABGi+WAAH2k9oAABBT3w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Actually, I am currently working with a bit old version of eyeBeam > (version > 3013), and the latest version of Express Talk. Both answer a hold request > according to the old RFC. > Can you recommend of any good free SIP clients out there which comply to > the latest RFC ? Actually I wonder that your eyeBeam does not follow RFC3264. I just tried my eyeBeam (Version 1.5.4) and found hold mechanism correctly implemented (I can send you the trace-file). Also the hardphones I use (snom and Thomson) have it correctly implemented. I don't use free clients since I have eyeBeam. regards Franz BTW: This seems to become more a question for the "sip-implementers" mailing-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 Mon May 08 05:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1nA-0002Zt-LO; Mon, 08 May 2006 05:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd1n8-0002Zn-Sd for sip@ietf.org; Mon, 08 May 2006 05:12:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd1n6-00006Y-HI for sip@ietf.org; Mon, 08 May 2006 05:12:34 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EA4D4F0001; Mon, 8 May 2006 11:12:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 11:12:25 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 11:12:24 +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] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 8 May 2006 11:12:23 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0EAA@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZwGO7jNMh7r1N4TbOJhUQ8ODkffQCZbz7w From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jeroen van Bemmel" , "Jesske, R" , X-OriginalArrivalTime: 08 May 2006 09:12:24.0758 (UTC) FILETIME=[85303560:01C6727F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >You are correct that it does not necessarily prevent us changing the = URI in a response in a "subsequent revision", but=20 >that is a different discussion from the discussion we have already had = and concluded on mid-dialog requests. I thought we now also have had a discussion about the responses, and = agreed that it from a pure protocol logic perspective would cause no = harm. >As I said before to Roland, if there is interest in doing this it = should be addressed in a separate I-D giving the=20 >background, requirements, mechanism, etc. Of course it can be done that way. But, isn't the issue that we then may = end up with two mechanisms of doing the same way - the "request way" = described in the connected identity draft, and the "response way" to be = described in another draft?=20 Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 05 May 2006 08:39 > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 >=20 > Hi, >=20 > >RFC3261 Section 12.2.1.1: "[...] It is expected that > mandatory reflection of the original To and From URI in mid-dialog=20 > requests will be deprecated in a > >subsequent revision of this specification." >=20 > Ok, I appologize for missing that. >=20 > However, that doesn't prevent us from also allowing to change the URI=20 > in responses in a "subsequence revision". >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- > From: "Christer Holmberg (JO/LMF)" > To: "Elwell, John" ; "Jesske, R"=20 > ; > Cc: ; > Sent: Friday, May 05, 2006 9:22 AM > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 >=20 >=20 > Hi, >=20 > >Technically it might work, but RFC3261 neither gives > permission to change > >the To header field URI in a response nor hints at a future > lifting of this > >restriction. >=20 > So, where does RFC3261 give permisson to change the To header field=20 > URI later in a request, then??? >=20 > I thought the changing of the URI was something that THIS GROUP has=20 > agreed is to be allowed. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 04 May 2006 21:55 > > To: Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > > > > > > Hi, > > > > From the safeness point of view, I thought we already > agreed (at least > > I haven't heard any disagreement) that doing it would not be unsafe, = > > since the arguments that modifying the To and/or From > header URI would > > affect the transaction logic were not true. > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 4. toukokuuta 2006 13:39 > > To: Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > > > > Roland, > > > > Well, you would need to convince the community that this is a=20 > > worthwhile and safe thing to do. Agreement to date is only to change = > > From and To header field URIs in mid-dialog requests. > > Changing the To header field URI in a response would > require separate > > agreement. I suggest you write an I-D and try to get > backing. However, > > I fear you will encounter strong opposition. > > > > Regards, > > > > John > > > > > -----Original Message----- > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > Sent: 04 May 2006 09:37 > > > To: Elwell, John; sip@ietf.org > > > Cc: chister.holmberg@ericsson.com;=20 > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > esasaki@NTT-AT.COM > > > Subject: AW: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > Dear John et all, > > > I'm sorry to go again into the opposite oppinion but I'm still in = > > > favour of enhancing the draft to provide identity in the To header = > > > field URI of a response. > > > > > > I don't know if we have to rediscuss all the possibilities and=20 > > > assumptions. But fact is that such a to header change would > > be useful > > > for some services. > > > > > > Best Regards > > > > > > Roland > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > An: sip@ietf.org > > > > Betreff: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > was raised > > > > subsequently. This mail initiates discussion on the first > > issue. I > > > > will initiate discussion on the other three issues in separate=20 > > > > mails. > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > this draft > > > > intentionally does not address response identity, and > > therefore the > > > > identity of a dialog-forming responder to an INVITE request is=20 > > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > > direction rather than in the response to the INVITE request. The = > > > > open issue is stated as: > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > URI in the To > > > > header field of a response to change compared with > > > the To header > > > > field in a request? This could convey a connected > > > identity in a > > > > response to an INVITE request, but it would not be=20 > > > > authenticated. > > > > Authentication would have to rely on transitive > > trust, which > > > > might > > > > be feasible in a closed environment where the sips > > > URI scheme is > > > > used." > > > > > > > > There was considerable list discussion on this shortly after > > > > IETF65 with no > > > > resolution. I won't attempt to summarise it. My opinion > > > (for what it's > > > > worth) is as follows. > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed To/From header = > > > > field URIs throughout a dialog (i.e., it anticipates that > > these will > > > > be allowed to change mid-dialog), it says nothing to warn of any = > > > > future removal of the requirement that the To header > field URI in > > > > the response be the same as that in the request. > > Therefore I believe > > > > it would be dangerous to specify such a change to the To header=20 > > > > field URI. > > > > > > > > 2. The prime motivation for this draft was to provide > > authenticated > > > > identity, i.e., to complement the sip-identity draft. An > > identity in > > > > the To header field of a response cannot be authenticated, for=20 > > > > reasons stated many times on this list and at meetings. > > Therefore, > > > > at least in the Internet, a response identity would have little=20 > > > > value. > > > > > > > > 3. A comprehensive list of reasons for not going down > > that path were > > > > given by Jon Peterson (editor of the Identity draft) in a > > message to > > > > this list on 5th April. > > > > > > > > 4. In closed environments an unauthenticated response > > identity might > > > > have some value. But this could be achieved using > > > P-Asserted-Identity, say, > > > > rather than bending the rules for To headers in responses. > > > > > > > > Therefore I am NOT in favour of enhancing the draft to provide=20 > > > > identity in the To header field URI of a response. Can > > people agree > > > > to this resolution of the issue? > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Internet-Drafts@ietf.org > [mailto:Internet-Drafts@ietf.org] > > > > > Sent: 26 April 2006 20:50 > > > > > To: i-d-announce@ietf.org > > > > > Cc: sip@ietf.org > > > > > Subject: [Sip] I-D > > ACTION:draft-ietf-sip-connected-identity-00.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=20 > > > > > Working Group of the IETF. > > > > > > > > > > Title : Connected Identity in the Session Initiation Protocol=20 > > > > > (SIP) > > > > > Author(s) : J. Elwell > > > > > Filename : > > draft-ietf-sip-connected-identity-00.txt > > > > > Pages : 20 > > > > > Date : 2006-4-26 > > > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > > (SIP) dialog- > > > > > forming request, the UAS can have a different identity > > > > from that in > > > > > the To header. This document provides a means for > > that 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 PSTN > > > > > behind a gateway. This document normatively updates RFC > > > > > 3261 (SIP). > > > > > This work is being discussed on the sip@ietf.org > > mailing list. > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > dentity-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.=20 > Login with > > > > > the username "anonymous" and a password of your > e-mail address. > > > > > After > > > logging in, > > > > > type "cd internet-drafts" and then "get=20 > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > 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 > > > > > > > > > > > > > > > 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-00.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in=20 > > > > > 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=20 > > > > > "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=20 > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 08 05:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2Fl-0003mM-8q; Mon, 08 May 2006 05:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2Fj-0003mH-Q6 for sip@ietf.org; Mon, 08 May 2006 05:42:07 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd2Fj-0001f9-BB for sip@ietf.org; Mon, 08 May 2006 05:42:07 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k489g4K3016643; Mon, 8 May 2006 03:42:04 -0600 (MDT) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [sip] sip mib - summary of changes due to LC comments Date: Mon, 8 May 2006 03:42:03 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip] sip mib - summary of changes due to LC comments Thread-Index: AcZyEUKjfuNdVmKzS7quG1MRC+xqUQAaRw/gAAEXBIA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Cullen Jennings , "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here is a summary of the sip mib changes due to last call comments. Let me and Kevin know if we missed anything. A new ID will be posted on = Friday May 12 reflecting those changes unless we hear anything. Jean-Fran=E7ois --- Comments #1, #2, #3 from Samir Srivastava Closed; no changes required. See http://www1.ietf.org/mail-archive/web/sip/current/msg13855.html And subsequent emails from Dan and Cullen. --- Comments from Cullen Jennings See http://www1.ietf.org/mail-archive/web/sip/current/msg13924.html --- Comment #4 re: SipTransportProtocol Closed; See http://www1.ietf.org/mail-archive/web/sip/current/msg13966.html New proposed new text: SipTransportProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that selected transport protocol is in some way dependent on the context of the object using this convention. If a bit has value 0, then that transport protocol is not selected. Combinations of bits can be set when multiple transport protocols are selected. bit 0 : a protocol other than those defined here. bit 1 : User Datagram Protocol. bit 2 : Transmission Control Protocol. bit 3 : Stream Control Transmission Protocol. bit 4 : Transport Layer Security Protocol over TCP. bit 5 : Transport Layer Security Protocol over SCTP. SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), -- RFC4168=20 tlsTcp(4) =20 tlsSctp(5) -- RFC 4168 } -- REFERENCE "RFC 3261, Section 18" -- REFERENCE "RFC 4168" --- Comment #5 Cullen wrote: > sipMaxTransactions - I really don't know how I would decide what to > report in most proxies or what an administrator would do with this > information. Max transaction per second would be a a way that might=20 > make more sense to me. I thought it was per second as well but you're right, re-reading the = text, it is not what is meant. Resolution: change text to reflect that sipMaxTransactions is max = transactions per second. New text: sipMaxTransactions OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum number of simultaneous transactions per second that the SIP entity can handle. In general the value of this object SHOULD reflect a level of transaction processing per second that is considered high enough to impact the systems CPU and/or memory resources to the point of deteriorating SIP call processing but not high enough to cause catastrophic system failure." --- Comment #6 Cullen wrote: > In sipOptionTagTable, I did not see how the HeaderField stuff ended up > with 0xA0. I imagine this is all right, it was just not obvious to me=20 > how this all worked. Resolution: editorial change. The BITS data type is defined by SMIv2 and folks deal with it through = SNMP agents & tools. But the text in the example could be more explicit = to say, for e.g.: Example: if a user agent client supports and requires the server to support reliability of provisional responses (IETF RFC 3262), this table contains a row with the option tag string '100rel' in sipOptionTag and the OCTET STRING value of '1010 0000' or '0xA0' in sipOptionTagHeaderField. -> note: given the example, we will also add an informative reference = to RFC 3262 --- Comment #7 Cullen wrote: > It seem that not many people use sipOrganization - do we really want > this is the mandatory group. Ok. Resolution: remove sipOrganization from sipCommonConfigGroup. --- Comment #8 Cullen wrote: > Given the many ways that UA determine what the next hop is, the > sipUACfgServerAddr left me feeling pretty uncomfortable. Resolution: No changes required. This table is for *basic* sip ua config and it is basic for sure yet = usable by some of the UA implementation. You can picture a simple case = when a UA is given its registrar server and/or an outbound sip proxy = address. I poked around using well-known names of SIP UA vendor companies (soft = phone and hard IP phones), and I quickly looked at their SIP = configuration menus and I found the following configurable via soft = menus: - SIP Proxy (used by some IP phones and soft clients) - Outbound Proxy - Register with Proxy: Indicates whether to enable SIP registration. = This parameter is ignored if a SIP proxy server is not specified. = =3D=3D> this would be a case where the Entityrole is both proxy && = registrar. Arguably, I agree we do not get into how UAs may discover their = registrar, outbound sip proxies or P-CSCFs and things may get more = complicated. But once the discovery mechanism is complete, this table = can be updated by the UA (note that we made this read-only because of = the many ways UAs can discover this or get configured for this). --- Comment #9 > On the sipProxyAUthMethod, what do you do if using both TLS and = Digest. > TLS often uses Digest at the same time. Resolution: No changes required. The MIB object allows this to be expressed: both the TLS and Digest bits = would be turned on (set to '1'). --- Comment #10 > in sipProxyAuthRealm, the comment about this may need to be stored per > user was concerning. I agree that in some cases it may need to be.=20 > However, I don't see how this MIB could work when it is per user. Do=20 > we just say this item is empty or ignored if it is per user? Does the > MIB work if it is per user and I just don't understand how? Agree, this needs to be clarified to have consistent implementations. Resolution:=20 - indicate that this object is the *default* realm value used by the = proxy in Proxy-Authenticate headers and, - add a note to say that in case of per user storage, the default = value is ignored by the proxy. Proposed new text: sipProxyAuthRealm OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the default realm value used in Proxy-Authenticate headers. Note that this MAY need to be stored per user, in which case, this default value is ignored." ...snip --- Comment #11:=20 > sipRegAlloowThirdParty - there are two definitions in common usage for > 3rd party reg. This is one of them. However, I don't know of any > deployment situations that allow this type of 3rd party reg. It is=20 > the other type that are allowed in practice. Do we need to this at > all? Do we need to update? Resolution: add reference to RFC 3261 section 10.2 in description txt = Proposed new text: sipRegAllowThirdParty OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether or not the Registrar SHOULD allow third party registrations as defined in RFC 3261 section 10.2. ...snip --- Comment #12 > sipUserAuthenticationFailures - when there is a successful > authentication, does this reset to zero. No based on the def of Counter32.=20 Also, based on the semantics of a Counter32 (rfc2578, rfc4181 section = 4.6.1.2), it is not ok to put in the DESCRIPTION clause of a = Counter32/64 that there is a requirement that it MUST reset at any = specific time/event (e.g. here, successful registration).=20 Also, note that the counter may not be initiated with a creation value = of zero - if we think we need this, we should look at ZeroBasedCounter32 = (rfc2021). Proposed resolution: by default, no changes. If folks feel strongly about this, and comment back on the thread, an = alternative could be using ZeroBasedCounter32. --- Comment #13 > s/Jennins/Jennings/ :-) Sorry, thank you for catching this. Will be corrected. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 06:55:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3MM-0003Pi-Id; Mon, 08 May 2006 06:53:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3ML-0003Pd-It for sip@ietf.org; Mon, 08 May 2006 06:53:01 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd3MI-0007o5-Ne for sip@ietf.org; Mon, 08 May 2006 06:53:01 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Mon, 8 May 2006 12:52:53 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 8 May 2006 12:52:52 +0200 Message-Id: <31529C1D0F94F24989CBC1BCDF3C04970818BE54@S4DE8PSAAGT.blf.telekom.de> From: "Jesske, R" To: christer.holmberg@ericsson.com, john.elwell@siemens.com, jbemmel@zonnet.nl, sip@ietf.org Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 8 May 2006 12:52:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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, As Christer said, I don't know if this is a straight way forward to = wait for an further document describing the other way around. We (seen from TISPAN purpose) have a requirement of an additional = connected identity in the response and that can be fulfilled by = changing the to header in the response.=20 The discussion showed it that there is no harm in changing the to = header field in a response. Why don't do it? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Gesendet: Montag, 8. Mai 2006 11:12 > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Betreff: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 >=20 >=20 > Hi,=20 >=20 > >You are correct that it does not necessarily prevent us=20 > changing the URI in a response in a "subsequent revision", but=20 > >that is a different discussion from the discussion we have=20 > already had and concluded on mid-dialog requests. >=20 > I thought we now also have had a discussion about the=20 > responses, and agreed that it from a pure protocol logic=20 > perspective would cause no harm. >=20 > >As I said before to Roland, if there is interest in doing=20 > this it should be addressed in a separate I-D giving the=20 > >background, requirements, mechanism, etc. >=20 > Of course it can be done that way. But, isn't the issue that=20 > we then may end up with two mechanisms of doing the same way=20 > - the "request way" described in the connected identity=20 > draft, and the "response way" to be described in another draft?=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 05 May 2006 08:39 > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > Hi, > >=20 > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > mandatory reflection of the original To and From URI in mid-dialog=20 > > requests will be deprecated in a > > >subsequent revision of this specification." > >=20 > > Ok, I appologize for missing that. > >=20 > > However, that doesn't prevent us from also allowing to=20 > change the URI=20 > > in responses in a "subsequence revision". > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: "Christer Holmberg (JO/LMF)" > > To: "Elwell, John" ; "Jesske, R"=20 > > ; > > Cc: ; > > Sent: Friday, May 05, 2006 9:22 AM > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi, > >=20 > > >Technically it might work, but RFC3261 neither gives > > permission to change > > >the To header field URI in a response nor hints at a future > > lifting of this > > >restriction. > >=20 > > So, where does RFC3261 give permisson to change the To header field = > > URI later in a request, then??? > >=20 > > I thought the changing of the URI was something that THIS GROUP has = > > agreed is to be allowed. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 04 May 2006 21:55 > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > Hi, > > > > > > From the safeness point of view, I thought we already > > agreed (at least > > > I haven't heard any disagreement) that doing it would not=20 > be unsafe,=20 > > > since the arguments that modifying the To and/or From > > header URI would > > > affect the transaction logic were not true. > > > > > > Regards, > > > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 4. toukokuuta 2006 13:39 > > > To: Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > Roland, > > > > > > Well, you would need to convince the community that this is a=20 > > > worthwhile and safe thing to do. Agreement to date is=20 > only to change=20 > > > From and To header field URIs in mid-dialog requests. > > > Changing the To header field URI in a response would > > require separate > > > agreement. I suggest you write an I-D and try to get > > backing. However, > > > I fear you will encounter strong opposition. > > > > > > Regards, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > Sent: 04 May 2006 09:37 > > > > To: Elwell, John; sip@ietf.org > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > esasaki@NTT-AT.COM > > > > Subject: AW: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Dear John et all, > > > > I'm sorry to go again into the opposite oppinion but=20 > I'm still in=20 > > > > favour of enhancing the draft to provide identity in=20 > the To header=20 > > > > field URI of a response. > > > > > > > > I don't know if we have to rediscuss all the possibilities and=20 > > > > assumptions. But fact is that such a to header change would > > > be useful > > > > for some services. > > > > > > > > Best Regards > > > > > > > > Roland > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > An: sip@ietf.org > > > > > Betreff: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > was raised > > > > > subsequently. This mail initiates discussion on the first > > > issue. I > > > > > will initiate discussion on the other three issues in=20 > separate=20 > > > > > mails. > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > this draft > > > > > intentionally does not address response identity, and > > > therefore the > > > > > identity of a dialog-forming responder to an INVITE=20 > request is=20 > > > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > > > direction rather than in the response to the INVITE=20 > request. The=20 > > > > > open issue is stated as: > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > URI in the To > > > > > header field of a response to change compared with > > > > the To header > > > > > field in a request? This could convey a connected > > > > identity in a > > > > > response to an INVITE request, but it would not be=20 > > > > > authenticated. > > > > > Authentication would have to rely on transitive > > > trust, which > > > > > might > > > > > be feasible in a closed environment where the sips > > > > URI scheme is > > > > > used." > > > > > > > > > > There was considerable list discussion on this shortly after > > > > > IETF65 with no > > > > > resolution. I won't attempt to summarise it. My opinion > > > > (for what it's > > > > > worth) is as follows. > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From header=20 > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > these will > > > > > be allowed to change mid-dialog), it says nothing to=20 > warn of any=20 > > > > > future removal of the requirement that the To header > > field URI in > > > > > the response be the same as that in the request. > > > Therefore I believe > > > > > it would be dangerous to specify such a change to the=20 > To header=20 > > > > > field URI. > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > authenticated > > > > > identity, i.e., to complement the sip-identity draft. An > > > identity in > > > > > the To header field of a response cannot be=20 > authenticated, for=20 > > > > > reasons stated many times on this list and at meetings. > > > Therefore, > > > > > at least in the Internet, a response identity would=20 > have little=20 > > > > > value. > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > that path were > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > message to > > > > > this list on 5th April. > > > > > > > > > > 4. In closed environments an unauthenticated response > > > identity might > > > > > have some value. But this could be achieved using > > > > P-Asserted-Identity, say, > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft=20 > to provide=20 > > > > > identity in the To header field URI of a response. Can > > > people agree > > > > > to this resolution of the issue? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > > > > > Sent: 26 April 2006 20:50 > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: sip@ietf.org > > > > > > Subject: [Sip] I-D > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > > directories. > > > > > > This draft is a work item of the Session Initiation=20 > Protocol=20 > > > > > > Working Group of the IETF. > > > > > > > > > > > > Title : Connected Identity in the Session=20 > Initiation Protocol=20 > > > > > > (SIP) > > > > > > Author(s) : J. Elwell > > > > > > Filename : > > > draft-ietf-sip-connected-identity-00.txt > > > > > > Pages : 20 > > > > > > Date : 2006-4-26 > > > > > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > > > (SIP) dialog- > > > > > > forming request, the UAS can have a different identity > > > > > from that in > > > > > > the To header. This document provides a means for > > > that 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 PSTN > > > > > > behind a gateway. This document normatively updates RFC > > > > > > 3261 (SIP). > > > > > > This work is being discussed on the sip@ietf.org > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > dentity-00.txt > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > message to > > > > > > i-d-announce-request@ietf.org with the word=20 > unsubscribe in the=20 > > > > > > 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.=20 > > Login with > > > > > > the username "anonymous" and a password of your > > e-mail address. > > > > > > After > > > > logging in, > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > 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-00.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > document in=20 > > > > > > 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=20 > > > > > > "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=20 > application of sip > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use = > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 08 07:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3XT-0006yf-M7; Mon, 08 May 2006 07:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd3XR-0006yZ-Pd for sip@ietf.org; Mon, 08 May 2006 07:04:29 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fd3XR-0000J3-E2 for sip@ietf.org; Mon, 08 May 2006 07:04:29 -0400 X-VirusChecked: Checked X-Env-Sender: Harsha.Gowda@lntinfotech.com X-Msg-Ref: server-7.tower-44.messagelabs.com!1147086261!20784411!4 X-StarScan-Version: 5.5.9.1; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 22468 invoked from network); 8 May 2006 11:04:26 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO Bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-7.tower-44.messagelabs.com with SMTP; 8 May 2006 11:04:26 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by Bangaloresmtp.lntinfotech.com (Lotus Domino Release 6.5.4) with ESMTP id 2006050816342525-87758 ; Mon, 8 May 2006 16:34:25 +0530 In-Reply-To: To: sip@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Harsha Gowda Date: Mon, 8 May 2006 16:34:20 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 6.5.5|November 30, 2005) at 05/08/2006 04:34:20 PM, Serialize complete at 05/08/2006 04:34:20 PM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 05/08/2006 04:34:25 PM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 6.5.4|March 27, 2005) at 05/08/2006 04:34:28 PM, Serialize complete at 05/08/2006 04:34:28 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Sip] Re: Sip Digest, Vol 25, Issue 10 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1789469105==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1789469105== Content-Type: multipart/alternative; boundary="=_alternative 003CD1C36525716E_=" This is a multipart message in MIME format. --=_alternative 003CD1C36525716E_= Content-Type: text/plain; charset="US-ASCII" Hi all, Please help Me I am using Ericsson SIP Core Reference Server I am using josua for user agent.. Platform is windows I am able to register, But when i invite to other who is also registered its giving 404 insted of 200 ok... Any Suggestion would be helpfull.. and modifed configuration file as below #-----------------------------start------------------------- # this file is used to store user config values # # empty lines are not accepted # comments starts with # # # !!!!!!! extra SPACES may lead to unknown behavior!!!!!! # # duplicates feilds are discarded... # no other restrictions # # logfile=log # # displayname=harsha username=harsha localip=172.28.7.191 #contact for INVITE global_contact= #contact for REGISTER contact= expires=3600 from= # localport=5060 # # oubound_proxy is a route-set to use for all requests. (outside of a dialog) # If you don't provide the lr parameter.. behavior will be VERY strange... # outbound_proxy= # registrar=sip:172.28.7.150 # #SDP config networktype=IN addr_type=IP4 # ______________________________________________________________________ --=_alternative 003CD1C36525716E_= Content-Type: text/html; charset="US-ASCII"
Hi all,
Please help Me



I am using Ericsson SIP Core Reference Server
I am using josua for user agent..
Platform is windows


I am able to register,
But when i invite to other who is also registered its giving 404
insted of 200 ok...

Any Suggestion would be helpfull..

and modifed configuration file as below



#-----------------------------start-------------------------
# this file is used to store user config values
#
# empty lines are not accepted
# comments starts with #
#
# !!!!!!! extra SPACES may lead to unknown behavior!!!!!!
#
# duplicates feilds are discarded...
# no other restrictions
#
#
logfile=log
#
#
displayname=harsha
username=harsha
localip=172.28.7.191
#contact for INVITE
global_contact=<sip:harsha@172.28.7.150>
#contact for REGISTER
contact=<sip:harsha@172.28.7.150>
expires=3600
from=<sip:harsha@172.28.7.150>
#
localport=5060
#
# oubound_proxy is a route-set to use for all requests. (outside of a dialog)
# If you don't provide the lr parameter.. behavior will be VERY strange...
#
outbound_proxy=<sip:172.28.7.150;lr>
#
registrar=sip:172.28.7.150
#
#SDP config
networktype=IN
addr_type=IP4
#


______________________________________________________________________
--=_alternative 003CD1C36525716E_=-- --===============1789469105== 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 --===============1789469105==-- From sip-bounces@ietf.org Mon May 08 08:11:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4X8-0002Wl-3F; Mon, 08 May 2006 08:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4X7-0002WG-2X for sip@ietf.org; Mon, 08 May 2006 08:08:13 -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 1Fd4X6-00042w-VG for sip@ietf.org; Mon, 08 May 2006 08:08:13 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd4X2-0005lQ-31 for sip@ietf.org; Mon, 08 May 2006 08:08:12 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYY000014E58V@siemenscomms.co.uk> for sip@ietf.org; Mon, 08 May 2006 13:08:29 +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 <0IYY00M974E30F@siemenscomms.co.uk>; Mon, 08 May 2006 13:08:27 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 08 May 2006 13:07:58 +0100 Content-return: allowed Date: Mon, 08 May 2006 13:07:55 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Jesske, R" , christer.holmberg@ericsson.com, jbemmel@zonnet.nl, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D78679@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Roland, I don't agree that discussion has shown that there is no harm in = changing the To header field URI in a response. There is no forewarning of this = in RFC3261. Even though we could use an option tag to ensure that a UA is compliant, we can anticipate problems with proxies. I repeat that we = need a separate I-D to discuss such issues. John=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 08 May 2006 11:53 > To: christer.holmberg@ericsson.com; Elwell, John;=20 > jbemmel@zonnet.nl; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: AW: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 > Hi, > As Christer said, I don't know if this is a straight way=20 > forward to wait for an further document describing the other=20 > way around. > We (seen from TISPAN purpose) have a requirement of an=20 > additional connected identity in the response and that can be=20 > fulfilled by changing the to header in the response.=20 > The discussion showed it that there is no harm in changing=20 > the to header field in a response. > Why don't do it? >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com]=20 > > Gesendet: Montag, 8. Mai 2006 11:12 > > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Betreff: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi,=20 > >=20 > > >You are correct that it does not necessarily prevent us=20 > > changing the URI in a response in a "subsequent revision", but=20 > > >that is a different discussion from the discussion we have=20 > > already had and concluded on mid-dialog requests. > >=20 > > I thought we now also have had a discussion about the=20 > > responses, and agreed that it from a pure protocol logic=20 > > perspective would cause no harm. > >=20 > > >As I said before to Roland, if there is interest in doing=20 > > this it should be addressed in a separate I-D giving the=20 > > >background, requirements, mechanism, etc. > >=20 > > Of course it can be done that way. But, isn't the issue that=20 > > we then may end up with two mechanisms of doing the same way=20 > > - the "request way" described in the connected identity=20 > > draft, and the "response way" to be described in another draft?=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 05 May 2006 08:39 > > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in=20 > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > > mandatory reflection of the original To and From URI in=20 > mid-dialog=20 > > > requests will be deprecated in a > > > >subsequent revision of this specification." > > >=20 > > > Ok, I appologize for missing that. > > >=20 > > > However, that doesn't prevent us from also allowing to=20 > > change the URI=20 > > > in responses in a "subsequence revision". > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > ----- Original Message ----- > > > From: "Christer Holmberg (JO/LMF)"=20 > > > > To: "Elwell, John" ; "Jesske, R"=20 > > > ; > > > Cc: ; > > > Sent: Friday, May 05, 2006 9:22 AM > > > Subject: RE: [Sip] Issue 1 in=20 > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > >Technically it might work, but RFC3261 neither gives > > > permission to change > > > >the To header field URI in a response nor hints at a future > > > lifting of this > > > >restriction. > > >=20 > > > So, where does RFC3261 give permisson to change the To=20 > header field=20 > > > URI later in a request, then??? > > >=20 > > > I thought the changing of the URI was something that THIS=20 > GROUP has=20 > > > agreed is to be allowed. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: 04 May 2006 21:55 > > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > Hi, > > > > > > > > From the safeness point of view, I thought we already > > > agreed (at least > > > > I haven't heard any disagreement) that doing it would not=20 > > be unsafe,=20 > > > > since the arguments that modifying the To and/or From > > > header URI would > > > > affect the transaction logic were not true. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 4. toukokuuta 2006 13:39 > > > > To: Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Roland, > > > > > > > > Well, you would need to convince the community that this is a=20 > > > > worthwhile and safe thing to do. Agreement to date is=20 > > only to change=20 > > > > From and To header field URIs in mid-dialog requests. > > > > Changing the To header field URI in a response would > > > require separate > > > > agreement. I suggest you write an I-D and try to get > > > backing. However, > > > > I fear you will encounter strong opposition. > > > > > > > > Regards, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > > Sent: 04 May 2006 09:37 > > > > > To: Elwell, John; sip@ietf.org > > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > > esasaki@NTT-AT.COM > > > > > Subject: AW: [Sip] Issue 1 in > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > Dear John et all, > > > > > I'm sorry to go again into the opposite oppinion but=20 > > I'm still in=20 > > > > > favour of enhancing the draft to provide identity in=20 > > the To header=20 > > > > > field URI of a response. > > > > > > > > > > I don't know if we have to rediscuss all the=20 > possibilities and=20 > > > > > assumptions. But fact is that such a to header change would > > > > be useful > > > > > for some services. > > > > > > > > > > Best Regards > > > > > > > > > > Roland > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > > An: sip@ietf.org > > > > > > Betreff: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > > was raised > > > > > > subsequently. This mail initiates discussion on the first > > > > issue. I > > > > > > will initiate discussion on the other three issues in=20 > > separate=20 > > > > > > mails. > > > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > > this draft > > > > > > intentionally does not address response identity, and > > > > therefore the > > > > > > identity of a dialog-forming responder to an INVITE=20 > > request is=20 > > > > > > conveyed in a separate request (e.g., UPDATE) in=20 > the reverse=20 > > > > > > direction rather than in the response to the INVITE=20 > > request. The=20 > > > > > > open issue is stated as: > > > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > > URI in the To > > > > > > header field of a response to change compared with > > > > > the To header > > > > > > field in a request? This could convey a connected > > > > > identity in a > > > > > > response to an INVITE request, but it would not be=20 > > > > > > authenticated. > > > > > > Authentication would have to rely on transitive > > > > trust, which > > > > > > might > > > > > > be feasible in a closed environment where the sips > > > > > URI scheme is > > > > > > used." > > > > > > > > > > > > There was considerable list discussion on this shortly = after > > > > > > IETF65 with no > > > > > > resolution. I won't attempt to summarise it. My opinion > > > > > (for what it's > > > > > > worth) is as follows. > > > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > > To/From header=20 > > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > > these will > > > > > > be allowed to change mid-dialog), it says nothing to=20 > > warn of any=20 > > > > > > future removal of the requirement that the To header > > > field URI in > > > > > > the response be the same as that in the request. > > > > Therefore I believe > > > > > > it would be dangerous to specify such a change to the=20 > > To header=20 > > > > > > field URI. > > > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > > authenticated > > > > > > identity, i.e., to complement the sip-identity draft. An > > > > identity in > > > > > > the To header field of a response cannot be=20 > > authenticated, for=20 > > > > > > reasons stated many times on this list and at meetings. > > > > Therefore, > > > > > > at least in the Internet, a response identity would=20 > > have little=20 > > > > > > value. > > > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > > that path were > > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > > message to > > > > > > this list on 5th April. > > > > > > > > > > > > 4. In closed environments an unauthenticated response > > > > identity might > > > > > > have some value. But this could be achieved using > > > > > P-Asserted-Identity, say, > > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft=20 > > to provide=20 > > > > > > identity in the To header field URI of a response. Can > > > > people agree > > > > > > to this resolution of the issue? > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Internet-Drafts@ietf.org > > > [mailto:Internet-Drafts@ietf.org] > > > > > > > Sent: 26 April 2006 20:50 > > > > > > > To: i-d-announce@ietf.org > > > > > > > Cc: sip@ietf.org > > > > > > > Subject: [Sip] I-D > > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > > directories. > > > > > > > This draft is a work item of the Session Initiation=20 > > Protocol=20 > > > > > > > Working Group of the IETF. > > > > > > > > > > > > > > Title : Connected Identity in the Session=20 > > Initiation Protocol=20 > > > > > > > (SIP) > > > > > > > Author(s) : J. Elwell > > > > > > > Filename : > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > Pages : 20 > > > > > > > Date : 2006-4-26 > > > > > > > > > > > > > > Because of retargeting of a Session Initiation = Protocol > > > > > > > (SIP) dialog- > > > > > > > forming request, the UAS can have a different identity > > > > > > from that in > > > > > > > the To header. This document provides a means for > > > > that 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 PSTN > > > > > > > behind a gateway. This document normatively=20 > updates RFC > > > > > > > 3261 (SIP). > > > > > > > This work is being discussed on the sip@ietf.org > > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > > dentity-00.txt > > > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > > message to > > > > > > > i-d-announce-request@ietf.org with the word=20 > > unsubscribe in the=20 > > > > > > > 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.=20 > > > Login with > > > > > > > the username "anonymous" and a password of your > > > e-mail address. > > > > > > > After > > > > > logging in, > > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > > > Send a message to: > > > > > > > mailserv@ietf.org. > > > > > > > In the body type: > > > > > > > "FILE > > > > > > >=20 > /internet-drafts/draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > > document in=20 > > > > > > > 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=20 > > > > > > > "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=20 > 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 = > > > 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 >=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 May 08 08:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4aF-0003lJ-3t; Mon, 08 May 2006 08:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4aD-0003lD-O2 for sip@ietf.org; Mon, 08 May 2006 08:11:25 -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 1Fd4aC-0004D0-TQ for sip@ietf.org; Mon, 08 May 2006 08:11:25 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYY000014IMN8@siemenscomms.co.uk> for sip@ietf.org; Mon, 08 May 2006 13:11:11 +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 <0IYY00MC14FI0F@siemenscomms.co.uk>; Mon, 08 May 2006 13:09:18 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 08 May 2006 13:08:49 +0100 Content-return: allowed Date: Mon, 08 May 2006 13:08:47 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Christer Holmberg (JO/LMF)" , Jeroen van Bemmel , "Jesske, R" , sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708D7867E@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Christer, Concerning the harmfulness or otherwise of changing the To header fie= ld URI in a response, see my reply to Roland. Concerning your "two mechanisms" concern, that is exactly what I am t= rying to avoid. We need the ability to send connected-identity in a mid-dia= log request because that is the only method we have at present of being a= ble to authenticate the identity, and also because of mid-dialog changes of identity. Concerning whether it is two documents or one, we can deal with that = if and when we have community consensus on response identity, provided that consensus is achieved in time. The proper procedure is write in I-D, = discuss by email and at IETF66, and then, if consensus on the mechanism is ac= hieved, discuss how best to document it (by incorporating into the existing connected-identity draft or keeping in a separate draft). I don't lik= e discussing documentation strategy before we have consensus on what we= want to document. John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 08 May 2006 10:12 > To: Elwell, John; Jeroen van Bemmel; Jesske, R; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.= txt >=20 >=20 > Hi,=20 >=20 > >You are correct that it does not necessarily prevent us=20 > changing the URI in a response in a "subsequent revision", but=20 > >that is a different discussion from the discussion we have=20 > already had and concluded on mid-dialog requests. >=20 > I thought we now also have had a discussion about the=20 > responses, and agreed that it from a pure protocol logic=20 > perspective would cause no harm. >=20 > >As I said before to Roland, if there is interest in doing=20 > this it should be addressed in a separate I-D giving the=20 > >background, requirements, mechanism, etc. >=20 > Of course it can be done that way. But, isn't the issue that=20 > we then may end up with two mechanisms of doing the same way=20 > - the "request way" described in the connected identity=20 > draft, and the "response way" to be described in another draft?= =20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 05 May 2006 08:39 > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > Hi, > >=20 > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > mandatory reflection of the original To and From URI in mid-dialo= g=20 > > requests will be deprecated in a > > >subsequent revision of this specification." > >=20 > > Ok, I appologize for missing that. > >=20 > > However, that doesn't prevent us from also allowing to=20 > change the URI=20 > > in responses in a "subsequence revision". > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: "Christer Holmberg (JO/LMF)" > > To: "Elwell, John" ; "Jesske, R"=20 > > ; > > Cc: ; > > Sent: Friday, May 05, 2006 9:22 AM > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi, > >=20 > > >Technically it might work, but RFC3261 neither gives > > permission to change > > >the To header field URI in a response nor hints at a future > > lifting of this > > >restriction. > >=20 > > So, where does RFC3261 give permisson to change the To header fie= ld=20 > > URI later in a request, then??? > >=20 > > I thought the changing of the URI was something that THIS GROUP h= as=20 > > agreed is to be allowed. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 04 May 2006 21:55 > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > Hi, > > > > > > From the safeness point of view, I thought we already > > agreed (at least > > > I haven't heard any disagreement) that doing it would not=20 > be unsafe,=20 > > > since the arguments that modifying the To and/or From > > header URI would > > > affect the transaction logic were not true. > > > > > > Regards, > > > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 4. toukokuuta 2006 13:39 > > > To: Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > Roland, > > > > > > Well, you would need to convince the community that this is a= =20 > > > worthwhile and safe thing to do. Agreement to date is=20 > only to change=20 > > > From and To header field URIs in mid-dialog requests. > > > Changing the To header field URI in a response would > > require separate > > > agreement. I suggest you write an I-D and try to get > > backing. However, > > > I fear you will encounter strong opposition. > > > > > > Regards, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > Sent: 04 May 2006 09:37 > > > > To: Elwell, John; sip@ietf.org > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > esasaki@NTT-AT.COM > > > > Subject: AW: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Dear John et all, > > > > I'm sorry to go again into the opposite oppinion but=20 > I'm still in=20 > > > > favour of enhancing the draft to provide identity in=20 > the To header=20 > > > > field URI of a response. > > > > > > > > I don't know if we have to rediscuss all the possibilities an= d=20 > > > > assumptions. But fact is that such a to header change would > > > be useful > > > > for some services. > > > > > > > > Best Regards > > > > > > > > Roland > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > An: sip@ietf.org > > > > > Betreff: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > was raised > > > > > subsequently. This mail initiates discussion on the first > > > issue. I > > > > > will initiate discussion on the other three issues in=20 > separate=20 > > > > > mails. > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > this draft > > > > > intentionally does not address response identity, and > > > therefore the > > > > > identity of a dialog-forming responder to an INVITE=20 > request is=20 > > > > > conveyed in a separate request (e.g., UPDATE) in the revers= e=20 > > > > > direction rather than in the response to the INVITE=20 > request. The=20 > > > > > open issue is stated as: > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > URI in the To > > > > > header field of a response to change compared with > > > > the To header > > > > > field in a request? This could convey a connected > > > > identity in a > > > > > response to an INVITE request, but it would not be= =20 > > > > > authenticated. > > > > > Authentication would have to rely on transitive > > > trust, which > > > > > might > > > > > be feasible in a closed environment where the sips > > > > URI scheme is > > > > > used." > > > > > > > > > > There was considerable list discussion on this shortly afte= r > > > > > IETF65 with no > > > > > resolution. I won't attempt to summarise it. My opinion > > > > (for what it's > > > > > worth) is as follows. > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From header=20 > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > these will > > > > > be allowed to change mid-dialog), it says nothing to=20 > warn of any=20 > > > > > future removal of the requirement that the To header > > field URI in > > > > > the response be the same as that in the request. > > > Therefore I believe > > > > > it would be dangerous to specify such a change to the=20 > To header=20 > > > > > field URI. > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > authenticated > > > > > identity, i.e., to complement the sip-identity draft. An > > > identity in > > > > > the To header field of a response cannot be=20 > authenticated, for=20 > > > > > reasons stated many times on this list and at meetings. > > > Therefore, > > > > > at least in the Internet, a response identity would=20 > have little=20 > > > > > value. > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > that path were > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > message to > > > > > this list on 5th April. > > > > > > > > > > 4. In closed environments an unauthenticated response > > > identity might > > > > > have some value. But this could be achieved using > > > > P-Asserted-Identity, say, > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft=20 > to provide=20 > > > > > identity in the To header field URI of a response. Can > > > people agree > > > > > to this resolution of the issue? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > > > > > Sent: 26 April 2006 20:50 > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: sip@ietf.org > > > > > > Subject: [Sip] I-D > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > > directories. > > > > > > This draft is a work item of the Session Initiation=20 > Protocol=20 > > > > > > Working Group of the IETF. > > > > > > > > > > > > Title : Connected Identity in the Session=20 > Initiation Protocol=20 > > > > > > (SIP) > > > > > > Author(s) : J. Elwell > > > > > > Filename : > > > draft-ietf-sip-connected-identity-00.txt > > > > > > Pages : 20 > > > > > > Date : 2006-4-26 > > > > > > > > > > > > Because of retargeting of a Session Initiation Protoco= l > > > > > > (SIP) dialog- > > > > > > forming request, the UAS can have a different identity > > > > > from that in > > > > > > the To header. This document provides a means for > > > that 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 PSTN > > > > > > behind a gateway. This document normatively updates R= FC > > > > > > 3261 (SIP). > > > > > > This work is being discussed on the sip@ietf.org > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > dentity-00.txt > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > message to > > > > > > i-d-announce-request@ietf.org with the word=20 > unsubscribe in the=20 > > > > > > 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.=20 > > Login with > > > > > > the username "anonymous" and a password of your > > e-mail address. > > > > > > After > > > > logging in, > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > 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-00.txt= ". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > document in=20 > > > > > > 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= =20 > > > > > > "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/si= p > > > > > This list is for NEW development of the core SIP Protocol U= se=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application 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 U= se=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use= =20 > > sip-implementors@cs.columbia.edu for questions on current sip Use= =20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 08 08:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4x4-0002j5-7P; Mon, 08 May 2006 08:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4x2-0002iQ-F2 for sip@ietf.org; Mon, 08 May 2006 08:35:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd4kT-0004pd-CG for sip@ietf.org; Mon, 08 May 2006 08:22:02 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 70B3D4F0001; Mon, 8 May 2006 14:21:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:21:58 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:21:57 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 8 May 2006 14:21:56 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0EAD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZymA72cXLRPqf0TCaqfnq9KbftMQAAN+1A From: "Christer Holmberg \(JO/LMF\)" To: "Elwell, John" , "Jesske, R" , , X-OriginalArrivalTime: 08 May 2006 12:21:57.0715 (UTC) FILETIME=[FFFFBA30:01C67299] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I don't agree that discussion has shown that there is no harm in = changing the To header field URI in a response. There is=20 >no forewarning of this in RFC3261.=20 I don't follow. Do you mean that we, in a current spec, need to "warn" = people about what will be changed/added in future revisions, and that we = are only allowed to do things in revision we have "warned" about in = earlier versions ?????? In most cases changes are done in revisions = because issues have been identified AFTER the previous version has been = released... And, EVEN if the current spec "warn" about something, that alone can not = be reason enough to say that it will cause no harm. If you expect = implementations to support something it shall be normative text - NOT = "hints" about what may happen in the future... >Even though we could use an option tag to ensure that a UA is = compliant, we can anticipate problems with proxies. I=20 >repeat that we need a separate I-D to discuss such issues. I think the discussion has showed that there will be no problems with = proxies. The only argument I've heard is that it would mess up the transaction = logic, but we have shown that is not the case. Regards, Christer > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net] > Sent: 08 May 2006 11:53 > To: christer.holmberg@ericsson.com; Elwell, John; jbemmel@zonnet.nl;=20 > sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 > Hi, > As Christer said, I don't know if this is a straight way forward to=20 > wait for an further document describing the other way around. > We (seen from TISPAN purpose) have a requirement of an additional=20 > connected identity in the response and that can be fulfilled by=20 > changing the to header in the response. > The discussion showed it that there is no harm in changing the to=20 > header field in a response. > Why don't do it? >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Gesendet: Montag, 8. Mai 2006 11:12 > > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Betreff: RE: [Sip] Issue 1 in > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi, > >=20 > > >You are correct that it does not necessarily prevent us > > changing the URI in a response in a "subsequent revision", but > > >that is a different discussion from the discussion we have > > already had and concluded on mid-dialog requests. > >=20 > > I thought we now also have had a discussion about the responses, and = > > agreed that it from a pure protocol logic perspective would cause no = > > harm. > >=20 > > >As I said before to Roland, if there is interest in doing > > this it should be addressed in a separate I-D giving the > > >background, requirements, mechanism, etc. > >=20 > > Of course it can be done that way. But, isn't the issue that we then = > > may end up with two mechanisms of doing the same way > > - the "request way" described in the connected identity draft, and=20 > > the "response way" to be described in another draft? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 05 May 2006 08:39 > > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > > mandatory reflection of the original To and From URI in > mid-dialog > > > requests will be deprecated in a > > > >subsequent revision of this specification." > > >=20 > > > Ok, I appologize for missing that. > > >=20 > > > However, that doesn't prevent us from also allowing to > > change the URI > > > in responses in a "subsequence revision". > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > ----- Original Message ----- > > > From: "Christer Holmberg (JO/LMF)"=20 > > > > To: "Elwell, John" ; "Jesske, R"=20 > > > ; > > > Cc: ; > > > Sent: Friday, May 05, 2006 9:22 AM > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > >Technically it might work, but RFC3261 neither gives > > > permission to change > > > >the To header field URI in a response nor hints at a future > > > lifting of this > > > >restriction. > > >=20 > > > So, where does RFC3261 give permisson to change the To > header field > > > URI later in a request, then??? > > >=20 > > > I thought the changing of the URI was something that THIS > GROUP has > > > agreed is to be allowed. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF)=20 > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: 04 May 2006 21:55 > > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > Hi, > > > > > > > > From the safeness point of view, I thought we already > > > agreed (at least > > > > I haven't heard any disagreement) that doing it would not > > be unsafe, > > > > since the arguments that modifying the To and/or From > > > header URI would > > > > affect the transaction logic were not true. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 4. toukokuuta 2006 13:39 > > > > To: Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Roland, > > > > > > > > Well, you would need to convince the community that this is a=20 > > > > worthwhile and safe thing to do. Agreement to date is > > only to change > > > > From and To header field URIs in mid-dialog requests. > > > > Changing the To header field URI in a response would > > > require separate > > > > agreement. I suggest you write an I-D and try to get > > > backing. However, > > > > I fear you will encounter strong opposition. > > > > > > > > Regards, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > > Sent: 04 May 2006 09:37 > > > > > To: Elwell, John; sip@ietf.org > > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > > esasaki@NTT-AT.COM > > > > > Subject: AW: [Sip] Issue 1 in > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > Dear John et all, > > > > > I'm sorry to go again into the opposite oppinion but > > I'm still in > > > > > favour of enhancing the draft to provide identity in > > the To header > > > > > field URI of a response. > > > > > > > > > > I don't know if we have to rediscuss all the > possibilities and > > > > > assumptions. But fact is that such a to header change would > > > > be useful > > > > > for some services. > > > > > > > > > > Best Regards > > > > > > > > > > Roland > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > > An: sip@ietf.org > > > > > > Betreff: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > > was raised > > > > > > subsequently. This mail initiates discussion on the first > > > > issue. I > > > > > > will initiate discussion on the other three issues in > > separate > > > > > > mails. > > > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > > this draft > > > > > > intentionally does not address response identity, and > > > > therefore the > > > > > > identity of a dialog-forming responder to an INVITE > > request is > > > > > > conveyed in a separate request (e.g., UPDATE) in > the reverse > > > > > > direction rather than in the response to the INVITE > > request. The > > > > > > open issue is stated as: > > > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > > URI in the To > > > > > > header field of a response to change compared with > > > > > the To header > > > > > > field in a request? This could convey a connected > > > > > identity in a > > > > > > response to an INVITE request, but it would not be=20 > > > > > > authenticated. > > > > > > Authentication would have to rely on transitive > > > > trust, which > > > > > > might > > > > > > be feasible in a closed environment where the sips > > > > > URI scheme is > > > > > > used." > > > > > > > > > > > > There was considerable list discussion on this shortly after > > > > > > IETF65 with no > > > > > > resolution. I won't attempt to summarise it. My opinion > > > > > (for what it's > > > > > > worth) is as follows. > > > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed > > To/From header > > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > > these will > > > > > > be allowed to change mid-dialog), it says nothing to > > warn of any > > > > > > future removal of the requirement that the To header > > > field URI in > > > > > > the response be the same as that in the request. > > > > Therefore I believe > > > > > > it would be dangerous to specify such a change to the > > To header > > > > > > field URI. > > > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > > authenticated > > > > > > identity, i.e., to complement the sip-identity draft. An > > > > identity in > > > > > > the To header field of a response cannot be > > authenticated, for > > > > > > reasons stated many times on this list and at meetings. > > > > Therefore, > > > > > > at least in the Internet, a response identity would > > have little > > > > > > value. > > > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > > that path were > > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > > message to > > > > > > this list on 5th April. > > > > > > > > > > > > 4. In closed environments an unauthenticated response > > > > identity might > > > > > > have some value. But this could be achieved using > > > > > P-Asserted-Identity, say, > > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft > > to provide > > > > > > identity in the To header field URI of a response. Can > > > > people agree > > > > > > to this resolution of the issue? > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Internet-Drafts@ietf.org > > > [mailto:Internet-Drafts@ietf.org] > > > > > > > Sent: 26 April 2006 20:50 > > > > > > > To: i-d-announce@ietf.org > > > > > > > Cc: sip@ietf.org > > > > > > > Subject: [Sip] I-D > > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > > directories. > > > > > > > This draft is a work item of the Session Initiation > > Protocol > > > > > > > Working Group of the IETF. > > > > > > > > > > > > > > Title : Connected Identity in the Session > > Initiation Protocol > > > > > > > (SIP) > > > > > > > Author(s) : J. Elwell > > > > > > > Filename : > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > Pages : 20 > > > > > > > Date : 2006-4-26 > > > > > > > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > > > > (SIP) dialog- > > > > > > > forming request, the UAS can have a different identity > > > > > > from that in > > > > > > > the To header. This document provides a means for > > > > that 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 PSTN > > > > > > > behind a gateway. This document normatively > updates RFC > > > > > > > 3261 (SIP). > > > > > > > This work is being discussed on the sip@ietf.org > > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > > dentity-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.=20 > > > Login with > > > > > > > the username "anonymous" and a password of your > > > e-mail address. > > > > > > > After > > > > > logging in, > > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > > > Send a message to: > > > > > > > mailserv@ietf.org. > > > > > > > In the body type: > > > > > > > "FILE > > > > > > >=20 > /internet-drafts/draft-ietf-sip-connected-identity-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=20 > > > > > > > "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=20 > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=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 May 08 08:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd53e-0003ow-R1; Mon, 08 May 2006 08:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd53d-0003or-4W for sip@ietf.org; Mon, 08 May 2006 08:41:49 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd53b-0006Fr-Pn for sip@ietf.org; Mon, 08 May 2006 08:41:49 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k48D4ODQ015253 for ; Mon, 8 May 2006 06:04:24 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k48CwsFT028208 for ; Mon, 8 May 2006 07:58:55 -0500 (CDT) Received: from motorola.com ([10.232.117.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 20:41:40 +0800 Message-ID: <445F3CF3.5000506@motorola.com> Date: Mon, 08 May 2006 18:13:31 +0530 From: Preeti agarwal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: sip@ietf.org References: X-OriginalArrivalTime: 08 May 2006 12:41:40.0560 (UTC) FILETIME=[C1078D00:01C6729C] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Sip] Answer Mode X-BeenThere: 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="===============0434692873==" Errors-To: sip-bounces@ietf.org --===============0434692873== Content-Type: multipart/alternative; boundary="------------010009070306070400050804" --------------010009070306070400050804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi All, Please let me know in whcih case we send answer mode as "?Answer-mode=Manual" in INVITE message. Please also send me the format for how to send the same . Thanks, Priti --------------010009070306070400050804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All,
Please let me know in whcih case we send answer mode as "?Answer-mode=Manual" in INVITE message. Please also send me the format for how to send the same .

Thanks,
Priti
--------------010009070306070400050804-- --===============0434692873== 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 --===============0434692873==-- From sip-bounces@ietf.org Mon May 08 10:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6sz-00087k-Em; Mon, 08 May 2006 10:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6sy-00087f-M1 for sip@ietf.org; Mon, 08 May 2006 10:38:56 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6sx-00044u-Ad for sip@ietf.org; Mon, 08 May 2006 10:38:56 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k48Eduj1026106 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 8 May 2006 09:39:57 -0500 In-Reply-To: <445F3CF3.5000506@motorola.com> References: <445F3CF3.5000506@motorola.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D5D027B-E8BA-4DCD-91B2-164E1D6C5043@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Answer Mode Date: Mon, 8 May 2006 09:38:52 -0500 To: Preeti agarwal X-Mailer: Apple Mail (2.749.3) 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 On May 8, 2006, at 7:43 AM, Preeti agarwal wrote: > Hi All, > Please let me know in whcih case we send answer mode as "?Answer- > mode=Manual" in INVITE message. Please also send me the format for > how to send the same . > According to the current draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-00.txt We have: Req-2: It MUST be possible for UAC to ask that the UAS answer the request only after UAS-user has actively directed UAS to answer this specific request. We refer to this as "manual answer mode". This mode is useful in "push to talk" applications where the sender requires a reassurance that somebody is listening. And the format is given as: Answer-Mode=Manual Although there is a note: Note for implementors: SIP Header field names and values are always compared in a case-insensitive manner. The pretty capitalization is just for readability. -- 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 May 08 10:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd77W-0004pA-F1; Mon, 08 May 2006 10:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd77U-0004p4-Ov for sip@ietf.org; Mon, 08 May 2006 10:53:56 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd77T-00054L-Fl for sip@ietf.org; Mon, 08 May 2006 10:53:56 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 7281819448B for ; Mon, 8 May 2006 16:53:49 +0200 (CEST) Received: from [192.168.1.38] ([192.168.1.38]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 16:53:39 +0200 In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F0EAD@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F0EAD@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 8 May 2006 16:53:36 +0200 To: "Christer Holmberg \(JO/LMF\)" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 08 May 2006 14:53:39.0650 (UTC) FILETIME=[312CCA20:01C672AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Cc: sip@ietf.org, "Elwell, John" , sip@ietf.orgList X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I agree with you that the argument that there is a hint in RFC3261 is=20 not really an argument for not considering changing the To header in a=20= SIP response. The real argument that John did mention is that there is=20= no mechanism for asserting a response identity. Regards, Hisham On May 8, 2006, at 2:21 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >> I don't agree that discussion has shown that there is no harm in=20 >> changing the To header field URI in a response. There is >> no forewarning of this in RFC3261. > > I don't follow. Do you mean that we, in a current spec, need to "warn"=20= > people about what will be changed/added in future revisions, and that=20= > we are only allowed to do things in revision we have "warned" about in=20= > earlier versions ?????? In most cases changes are done in revisions=20 > because issues have been identified AFTER the previous version has=20 > been released... > > And, EVEN if the current spec "warn" about something, that alone can=20= > not be reason enough to say that it will cause no harm. If you expect=20= > implementations to support something it shall be normative text - NOT=20= > "hints" about what may happen in the future... > >> Even though we could use an option tag to ensure that a UA is=20 >> compliant, we can anticipate problems with proxies. I >> repeat that we need a separate I-D to discuss such issues. > > I think the discussion has showed that there will be no problems with=20= > proxies. > > The only argument I've heard is that it would mess up the transaction=20= > logic, but we have shown that is not the case. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 08 May 2006 11:53 >> To: christer.holmberg@ericsson.com; Elwell, John; jbemmel@zonnet.nl; >> sip@ietf.org >> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >> Subject: AW: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >> >> Hi, >> As Christer said, I don't know if this is a straight way forward to >> wait for an further document describing the other way around. >> We (seen from TISPAN purpose) have a requirement of an additional >> connected identity in the response and that can be fulfilled by >> changing the to header in the response. >> The discussion showed it that there is no harm in changing the to >> header field in a response. >> Why don't do it? >> >> Best Regards >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Gesendet: Montag, 8. Mai 2006 11:12 >>> An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org >>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>> Betreff: RE: [Sip] Issue 1 in >> draft-ietf-sip-connected-identity-00.txt >>> >>> >>> >>> Hi, >>> >>>> You are correct that it does not necessarily prevent us >>> changing the URI in a response in a "subsequent revision", but >>>> that is a different discussion from the discussion we have >>> already had and concluded on mid-dialog requests. >>> >>> I thought we now also have had a discussion about the responses, and >>> agreed that it from a pure protocol logic perspective would cause no >>> harm. >>> >>>> As I said before to Roland, if there is interest in doing >>> this it should be addressed in a separate I-D giving the >>>> background, requirements, mechanism, etc. >>> >>> Of course it can be done that way. But, isn't the issue that we then >>> may end up with two mechanisms of doing the same way >>> - the "request way" described in the connected identity draft, and >>> the "response way" to be described in another draft? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg (JO/LMF) >>>> [mailto:christer.holmberg@ericsson.com] >>>> Sent: 05 May 2006 08:39 >>>> To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org >>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>> Subject: RE: [Sip] Issue 1 in >>> draft-ietf-sip-connected-identity-00.txt >>>> >>>> >>>> Hi, >>>> >>>>> RFC3261 Section 12.2.1.1: "[...] It is expected that >>>> mandatory reflection of the original To and =46rom URI in >> mid-dialog >>>> requests will be deprecated in a >>>>> subsequent revision of this specification." >>>> >>>> Ok, I appologize for missing that. >>>> >>>> However, that doesn't prevent us from also allowing to >>> change the URI >>>> in responses in a "subsequence revision". >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Christer Holmberg (JO/LMF)" >> >>>> To: "Elwell, John" ; "Jesske, R" >>>> ; >>>> Cc: ; >>>> Sent: Friday, May 05, 2006 9:22 AM >>>> Subject: RE: [Sip] Issue 1 in >>> draft-ietf-sip-connected-identity-00.txt >>>> >>>> >>>> >>>> Hi, >>>> >>>>> Technically it might work, but RFC3261 neither gives >>>> permission to change >>>>> the To header field URI in a response nor hints at a future >>>> lifting of this >>>>> restriction. >>>> >>>> So, where does RFC3261 give permisson to change the To >> header field >>>> URI later in a request, then??? >>>> >>>> I thought the changing of the URI was something that THIS >> GROUP has >>>> agreed is to be allowed. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg (JO/LMF) >>>>> [mailto:christer.holmberg@ericsson.com] >>>>> Sent: 04 May 2006 21:55 >>>>> To: Elwell, John; Jesske, R; sip@ietf.org >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> =46rom the safeness point of view, I thought we already >>>> agreed (at least >>>>> I haven't heard any disagreement) that doing it would not >>> be unsafe, >>>>> since the arguments that modifying the To and/or From >>>> header URI would >>>>> affect the transaction logic were not true. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>> Sent: 4. toukokuuta 2006 13:39 >>>>> To: Jesske, R; sip@ietf.org >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>> >>>>> Roland, >>>>> >>>>> Well, you would need to convince the community that this is a >>>>> worthwhile and safe thing to do. Agreement to date is >>> only to change >>>>> =46rom and To header field URIs in mid-dialog requests. >>>>> Changing the To header field URI in a response would >>>> require separate >>>>> agreement. I suggest you write an I-D and try to get >>>> backing. However, >>>>> I fear you will encounter strong opposition. >>>>> >>>>> Regards, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Jesske, R [mailto:R.Jesske@t-com.net] >>>>>> Sent: 04 May 2006 09:37 >>>>>> To: Elwell, John; sip@ietf.org >>>>>> Cc: chister.holmberg@ericsson.com; >>>>>> sebastien.garcin@francetelecom.com; Alexeitsev, D; >>>>> esasaki@NTT-AT.COM >>>>>> Subject: AW: [Sip] Issue 1 in >>>>> draft-ietf-sip-connected-identity-00.txt >>>>>> >>>>>> Dear John et all, >>>>>> I'm sorry to go again into the opposite oppinion but >>> I'm still in >>>>>> favour of enhancing the draft to provide identity in >>> the To header >>>>>> field URI of a response. >>>>>> >>>>>> I don't know if we have to rediscuss all the >> possibilities and >>>>>> assumptions. But fact is that such a to header change would >>>>> be useful >>>>>> for some services. >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>> Von: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>> Gesendet: Dienstag, 2. Mai 2006 22:20 >>>>>>> An: sip@ietf.org >>>>>>> Betreff: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>>>> >>>>>>> >>>>>>> There are three open issues in this draft and a fourth that >>>>>> was raised >>>>>>> subsequently. This mail initiates discussion on the first >>>>> issue. I >>>>>>> will initiate discussion on the other three issues in >>> separate >>>>>>> mails. >>>>>>> >>>>>>> Issue 1 appears in section 5 and concerns the fact that >>>>> this draft >>>>>>> intentionally does not address response identity, and >>>>> therefore the >>>>>>> identity of a dialog-forming responder to an INVITE >>> request is >>>>>>> conveyed in a separate request (e.g., UPDATE) in >> the reverse >>>>>>> direction rather than in the response to the INVITE >>> request. The >>>>>>> open issue is stated as: >>>>>>> >>>>>>> "OPEN ISSUE. Should this be extended to allow a >>>>> URI in the To >>>>>>> header field of a response to change compared with >>>>>> the To header >>>>>>> field in a request? This could convey a connected >>>>>> identity in a >>>>>>> response to an INVITE request, but it would not be >>>>>>> authenticated. >>>>>>> Authentication would have to rely on transitive >>>>> trust, which >>>>>>> might >>>>>>> be feasible in a closed environment where the sips >>>>>> URI scheme is >>>>>>> used." >>>>>>> >>>>>>> There was considerable list discussion on this shortly after >>>>>>> IETF65 with no >>>>>>> resolution. I won't attempt to summarise it. My opinion >>>>>> (for what it's >>>>>>> worth) is as follows. >>>>>>> >>>>>>> 1. Whereas RFC 3261 anticipates deprecating fixed >>> To/=46rom header >>>>>>> field URIs throughout a dialog (i.e., it anticipates that >>>>> these will >>>>>>> be allowed to change mid-dialog), it says nothing to >>> warn of any >>>>>>> future removal of the requirement that the To header >>>> field URI in >>>>>>> the response be the same as that in the request. >>>>> Therefore I believe >>>>>>> it would be dangerous to specify such a change to the >>> To header >>>>>>> field URI. >>>>>>> >>>>>>> 2. The prime motivation for this draft was to provide >>>>> authenticated >>>>>>> identity, i.e., to complement the sip-identity draft. An >>>>> identity in >>>>>>> the To header field of a response cannot be >>> authenticated, for >>>>>>> reasons stated many times on this list and at meetings. >>>>> Therefore, >>>>>>> at least in the Internet, a response identity would >>> have little >>>>>>> value. >>>>>>> >>>>>>> 3. A comprehensive list of reasons for not going down >>>>> that path were >>>>>>> given by Jon Peterson (editor of the Identity draft) in a >>>>> message to >>>>>>> this list on 5th April. >>>>>>> >>>>>>> 4. In closed environments an unauthenticated response >>>>> identity might >>>>>>> have some value. But this could be achieved using >>>>>> P-Asserted-Identity, say, >>>>>>> rather than bending the rules for To headers in responses. >>>>>>> >>>>>>> Therefore I am NOT in favour of enhancing the draft >>> to provide >>>>>>> identity in the To header field URI of a response. Can >>>>> people agree >>>>>>> to this resolution of the issue? >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Internet-Drafts@ietf.org >>>> [mailto:Internet-Drafts@ietf.org] >>>>>>>> Sent: 26 April 2006 20:50 >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: sip@ietf.org >>>>>>>> Subject: [Sip] I-D >>>>> ACTION:draft-ietf-sip-connected-identity-00.txt >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Session Initiation >>> Protocol >>>>>>>> Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Connected Identity in the Session >>> Initiation Protocol >>>>>>>> (SIP) >>>>>>>> Author(s) : J. Elwell >>>>>>>> Filename : >>>>> draft-ietf-sip-connected-identity-00.txt >>>>>>>> Pages : 20 >>>>>>>> Date : 2006-4-26 >>>>>>>> >>>>>>>> Because of retargeting of a Session Initiation Protocol >>>>>>>> (SIP) dialog- >>>>>>>> forming request, the UAS can have a different identity >>>>>>> from that in >>>>>>>> the To header. This document provides a means for >>>>> that 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 PSTN >>>>>>>> behind a gateway. This document normatively >> updates RFC >>>>>>>> 3261 (SIP). >>>>>>>> This work is being discussed on the sip@ietf.org >>>>> mailing list. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i >>>>>>>> dentity-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-connected-identity-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-connected-identity-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 >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 11:39:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7nJ-0001by-6g; Mon, 08 May 2006 11:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7n8-0001T8-Ep for sip@ietf.org; Mon, 08 May 2006 11:36:58 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7kF-0007D6-Js for sip@ietf.org; Mon, 08 May 2006 11:34:00 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F22FFD18; Mon, 8 May 2006 17:33:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 17:33:58 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 17:33: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 8 May 2006 17:33:57 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0EB2@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Thread-Index: AcZyrzmM4V2NgZLrQzqePhZbUWsl7QABV2OA From: "Christer Holmberg \(JO/LMF\)" To: "Hisham Khartabil" X-OriginalArrivalTime: 08 May 2006 15:33:58.0130 (UTC) FILETIME=[D2B38D20:01C672B4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: sip@ietf.org, "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 Hi,=20 >I agree with you that the argument that there is a hint in RFC3261 is = not really an argument for not considering changing=20 >the To header in a SIP response. The real argument that John did = mention is that there is no mechanism for asserting a=20 >response identity. I don't think we have a requirement to assert the identity in a = response.=20 Regards, Christer On May 8, 2006, at 2:21 PM, Christer Holmberg ((JO/LMF)) wrote: > > Hi, > >> I don't agree that discussion has shown that there is no harm in=20 >> changing the To header field URI in a response. There is no=20 >> forewarning of this in RFC3261. > > I don't follow. Do you mean that we, in a current spec, need to "warn" = > people about what will be changed/added in future revisions, and that=20 > we are only allowed to do things in revision we have "warned" about in = > earlier versions ?????? In most cases changes are done in revisions=20 > because issues have been identified AFTER the previous version has=20 > been released... > > And, EVEN if the current spec "warn" about something, that alone can=20 > not be reason enough to say that it will cause no harm. If you expect=20 > implementations to support something it shall be normative text - NOT=20 > "hints" about what may happen in the future... > >> Even though we could use an option tag to ensure that a UA is=20 >> compliant, we can anticipate problems with proxies. I repeat that we=20 >> need a separate I-D to discuss such issues. > > I think the discussion has showed that there will be no problems with=20 > proxies. > > The only argument I've heard is that it would mess up the transaction=20 > logic, but we have shown that is not the case. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Jesske, R [mailto:R.Jesske@t-com.net] >> Sent: 08 May 2006 11:53 >> To: christer.holmberg@ericsson.com; Elwell, John; jbemmel@zonnet.nl;=20 >> sip@ietf.org >> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >> Subject: AW: [Sip] Issue 1 in=20 >> draft-ietf-sip-connected-identity-00.txt >> >> Hi, >> As Christer said, I don't know if this is a straight way forward to=20 >> wait for an further document describing the other way around. >> We (seen from TISPAN purpose) have a requirement of an additional=20 >> connected identity in the response and that can be fulfilled by=20 >> changing the to header in the response. >> The discussion showed it that there is no harm in changing the to=20 >> header field in a response. >> Why don't do it? >> >> Best Regards >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Gesendet: Montag, 8. Mai 2006 11:12 >>> An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org >>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>> Betreff: RE: [Sip] Issue 1 in >> draft-ietf-sip-connected-identity-00.txt >>> >>> >>> >>> Hi, >>> >>>> You are correct that it does not necessarily prevent us >>> changing the URI in a response in a "subsequent revision", but >>>> that is a different discussion from the discussion we have >>> already had and concluded on mid-dialog requests. >>> >>> I thought we now also have had a discussion about the responses, and = >>> agreed that it from a pure protocol logic perspective would cause no = >>> harm. >>> >>>> As I said before to Roland, if there is interest in doing >>> this it should be addressed in a separate I-D giving the >>>> background, requirements, mechanism, etc. >>> >>> Of course it can be done that way. But, isn't the issue that we then = >>> may end up with two mechanisms of doing the same way >>> - the "request way" described in the connected identity draft, and=20 >>> the "response way" to be described in another draft? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg (JO/LMF) >>>> [mailto:christer.holmberg@ericsson.com] >>>> Sent: 05 May 2006 08:39 >>>> To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org >>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>> Subject: RE: [Sip] Issue 1 in >>> draft-ietf-sip-connected-identity-00.txt >>>> >>>> >>>> Hi, >>>> >>>>> RFC3261 Section 12.2.1.1: "[...] It is expected that >>>> mandatory reflection of the original To and From URI in >> mid-dialog >>>> requests will be deprecated in a >>>>> subsequent revision of this specification." >>>> >>>> Ok, I appologize for missing that. >>>> >>>> However, that doesn't prevent us from also allowing to >>> change the URI >>>> in responses in a "subsequence revision". >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Christer Holmberg (JO/LMF)" >> >>>> To: "Elwell, John" ; "Jesske, R" >>>> ; >>>> Cc: ; >>>> Sent: Friday, May 05, 2006 9:22 AM >>>> Subject: RE: [Sip] Issue 1 in >>> draft-ietf-sip-connected-identity-00.txt >>>> >>>> >>>> >>>> Hi, >>>> >>>>> Technically it might work, but RFC3261 neither gives >>>> permission to change >>>>> the To header field URI in a response nor hints at a future >>>> lifting of this >>>>> restriction. >>>> >>>> So, where does RFC3261 give permisson to change the To >> header field >>>> URI later in a request, then??? >>>> >>>> I thought the changing of the URI was something that THIS >> GROUP has >>>> agreed is to be allowed. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg (JO/LMF) >>>>> [mailto:christer.holmberg@ericsson.com] >>>>> Sent: 04 May 2006 21:55 >>>>> To: Elwell, John; Jesske, R; sip@ietf.org >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> From the safeness point of view, I thought we already >>>> agreed (at least >>>>> I haven't heard any disagreement) that doing it would not >>> be unsafe, >>>>> since the arguments that modifying the To and/or From >>>> header URI would >>>>> affect the transaction logic were not true. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>> Sent: 4. toukokuuta 2006 13:39 >>>>> To: Jesske, R; sip@ietf.org >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com >>>>> Subject: RE: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>> >>>>> Roland, >>>>> >>>>> Well, you would need to convince the community that this is a=20 >>>>> worthwhile and safe thing to do. Agreement to date is >>> only to change >>>>> From and To header field URIs in mid-dialog requests. >>>>> Changing the To header field URI in a response would >>>> require separate >>>>> agreement. I suggest you write an I-D and try to get >>>> backing. However, >>>>> I fear you will encounter strong opposition. >>>>> >>>>> Regards, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Jesske, R [mailto:R.Jesske@t-com.net] >>>>>> Sent: 04 May 2006 09:37 >>>>>> To: Elwell, John; sip@ietf.org >>>>>> Cc: chister.holmberg@ericsson.com;=20 >>>>>> sebastien.garcin@francetelecom.com; Alexeitsev, D; >>>>> esasaki@NTT-AT.COM >>>>>> Subject: AW: [Sip] Issue 1 in >>>>> draft-ietf-sip-connected-identity-00.txt >>>>>> >>>>>> Dear John et all, >>>>>> I'm sorry to go again into the opposite oppinion but >>> I'm still in >>>>>> favour of enhancing the draft to provide identity in >>> the To header >>>>>> field URI of a response. >>>>>> >>>>>> I don't know if we have to rediscuss all the >> possibilities and >>>>>> assumptions. But fact is that such a to header change would >>>>> be useful >>>>>> for some services. >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Roland >>>>>> >>>>>> >>>>>>> -----Urspr=FCngliche Nachricht----- >>>>>>> Von: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>> Gesendet: Dienstag, 2. Mai 2006 22:20 >>>>>>> An: sip@ietf.org >>>>>>> Betreff: [Sip] Issue 1 in >>>> draft-ietf-sip-connected-identity-00.txt >>>>>>> >>>>>>> >>>>>>> There are three open issues in this draft and a fourth that >>>>>> was raised >>>>>>> subsequently. This mail initiates discussion on the first >>>>> issue. I >>>>>>> will initiate discussion on the other three issues in >>> separate >>>>>>> mails. >>>>>>> >>>>>>> Issue 1 appears in section 5 and concerns the fact that >>>>> this draft >>>>>>> intentionally does not address response identity, and >>>>> therefore the >>>>>>> identity of a dialog-forming responder to an INVITE >>> request is >>>>>>> conveyed in a separate request (e.g., UPDATE) in >> the reverse >>>>>>> direction rather than in the response to the INVITE >>> request. The >>>>>>> open issue is stated as: >>>>>>> >>>>>>> "OPEN ISSUE. Should this be extended to allow a >>>>> URI in the To >>>>>>> header field of a response to change compared with >>>>>> the To header >>>>>>> field in a request? This could convey a connected >>>>>> identity in a >>>>>>> response to an INVITE request, but it would not be=20 >>>>>>> authenticated. >>>>>>> Authentication would have to rely on transitive >>>>> trust, which >>>>>>> might >>>>>>> be feasible in a closed environment where the sips >>>>>> URI scheme is >>>>>>> used." >>>>>>> >>>>>>> There was considerable list discussion on this shortly after >>>>>>> IETF65 with no >>>>>>> resolution. I won't attempt to summarise it. My opinion >>>>>> (for what it's >>>>>>> worth) is as follows. >>>>>>> >>>>>>> 1. Whereas RFC 3261 anticipates deprecating fixed >>> To/From header >>>>>>> field URIs throughout a dialog (i.e., it anticipates that >>>>> these will >>>>>>> be allowed to change mid-dialog), it says nothing to >>> warn of any >>>>>>> future removal of the requirement that the To header >>>> field URI in >>>>>>> the response be the same as that in the request. >>>>> Therefore I believe >>>>>>> it would be dangerous to specify such a change to the >>> To header >>>>>>> field URI. >>>>>>> >>>>>>> 2. The prime motivation for this draft was to provide >>>>> authenticated >>>>>>> identity, i.e., to complement the sip-identity draft. An >>>>> identity in >>>>>>> the To header field of a response cannot be >>> authenticated, for >>>>>>> reasons stated many times on this list and at meetings. >>>>> Therefore, >>>>>>> at least in the Internet, a response identity would >>> have little >>>>>>> value. >>>>>>> >>>>>>> 3. A comprehensive list of reasons for not going down >>>>> that path were >>>>>>> given by Jon Peterson (editor of the Identity draft) in a >>>>> message to >>>>>>> this list on 5th April. >>>>>>> >>>>>>> 4. In closed environments an unauthenticated response >>>>> identity might >>>>>>> have some value. But this could be achieved using >>>>>> P-Asserted-Identity, say, >>>>>>> rather than bending the rules for To headers in responses. >>>>>>> >>>>>>> Therefore I am NOT in favour of enhancing the draft >>> to provide >>>>>>> identity in the To header field URI of a response. Can >>>>> people agree >>>>>>> to this resolution of the issue? >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Internet-Drafts@ietf.org >>>> [mailto:Internet-Drafts@ietf.org] >>>>>>>> Sent: 26 April 2006 20:50 >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: sip@ietf.org >>>>>>>> Subject: [Sip] I-D >>>>> ACTION:draft-ietf-sip-connected-identity-00.txt >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Session Initiation >>> Protocol >>>>>>>> Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Connected Identity in the Session >>> Initiation Protocol >>>>>>>> (SIP) >>>>>>>> Author(s) : J. Elwell >>>>>>>> Filename : >>>>> draft-ietf-sip-connected-identity-00.txt >>>>>>>> Pages : 20 >>>>>>>> Date : 2006-4-26 >>>>>>>> >>>>>>>> Because of retargeting of a Session Initiation Protocol >>>>>>>> (SIP) dialog- >>>>>>>> forming request, the UAS can have a different identity >>>>>>> from that in >>>>>>>> the To header. This document provides a means for >>>>> that 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 PSTN >>>>>>>> behind a gateway. This document normatively >> updates RFC >>>>>>>> 3261 (SIP). >>>>>>>> This work is being discussed on the sip@ietf.org >>>>> mailing list. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i >>>>>>>> dentity-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=20 >>>>>>>> draft-ietf-sip-connected-identity-00.txt". >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> 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-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=20 >>>>>>>> "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=20 >>>>> sip-implementors@cs.columbia.edu for questions on >> current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use=20 >>>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use=20 >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>> sipping@ietf.org for new developments on the application of sip >>> >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 08 11:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7wx-0002Jh-6t; Mon, 08 May 2006 11:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7ww-0002Ja-55 for sip@ietf.org; Mon, 08 May 2006 11:47:06 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7wu-00083s-UA for sip@ietf.org; Mon, 08 May 2006 11:47:06 -0400 Received: from hydra.cs.columbia.edu (IDENT:dsSG391EWkxHYGby1sqkH2jST2GticiF@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k48FktX6020513 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 May 2006 11:47:01 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:seBOdpwD6JkSbfoPtv1pu2lOkqU+UCsw@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id k48Fkoah016569; Mon, 8 May 2006 11:46:50 -0400 Received: from 24.199.99.149 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Mon, 8 May 2006 11:46:55 -0400 (EDT) Message-ID: <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> In-Reply-To: <445F3CF3.5000506@motorola.com> References: <445F3CF3.5000506@motorola.com> Date: Mon, 8 May 2006 11:46:55 -0400 (EDT) Subject: Re: [Sip] Answer Mode From: ac2491@cs.columbia.edu To: "Preeti agarwal" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.7 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Preeti, For my aplication I used Answer-mode as auto and appropriately handled SIP signalling (draft should suggest usage). If it was not auto application defaulted to manual (SIP signalling for manual ie human intervention (pick up phone) for call setup). Thanks -Anurag > Hi All, > Please let me know in whcih case we send answer mode as > "?Answer-mode=Manual" in INVITE message. Please also send me the format > for how to send the same . > > Thanks, > Priti > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 13:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd98Z-00078t-67; Mon, 08 May 2006 13:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkqW-0003Ic-19 for sip@ietf.org; Thu, 04 May 2006 16:54:48 -0400 Received: from shardagate.techmahindra.com ([202.67.5.4] helo=shardagate.mahindrabt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbkq2-0007FY-QA for sip@ietf.org; Thu, 04 May 2006 16:54:48 -0400 Received: from imss-sh-isp1 ([10.5.2.145]) by shardagate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id k44LDCwP001322 for ; Fri, 5 May 2006 02:43:12 +0530 Received: from IMSS-1 ([10.5.3.66]) by imss-sh-isp1 with InterScan Messaging Security Suite; Thu, 04 May 2006 17:43:39 +0530 Received: from dscp04509 ([10.5.13.88]) by IMSS-1 with InterScan Messaging Security Suite; Thu, 04 May 2006 17:44:50 +0530 Message-ID: <005301c66f72$aaa6a280$580d050a@mahindrabt.com> From: "Pooja Mittal" To: "Sudhir" , References: <52db68bc0605030559j5aec2cfar381e82697f97a26f@mail.gmail.com> Subject: Re: [Sip] query regarding BYE request-URI Date: Thu, 4 May 2006 17:32:50 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1807 X-imss-version: 2.038 X-imss-result: Passed X-imss-approveListMatch: *@techmahindra.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff X-Mailman-Approved-At: Mon, 08 May 2006 13:03:08 -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: , Content-Type: multipart/mixed; boundary="===============1146473048==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1146473048== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C66FA0.C457B290" This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C66FA0.C457B290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, You can refer to Section 16.12.1.2 of RFC 3261. Regards, Pooja ----- Original Message -----=0D From: Sudhir=0D To: sip@ietf.org=0D Sent: Wednesday, May 03, 2006 6:29 PM Subject: [Sip] query regarding BYE request-URI Hi All, If UA received INVITE request with contact and record-route header, when= UA want to built the BYE request. How BYE request-URI is built? Should I use either record-route or contact= header to construct BYE request-URI? Any response is appreciated=0D Thanks in advance Sudhir ---------------------------------------------------------------------------= --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tech Mahindra, formerly Mahindra-British Telecom. =0D Disclaimer: The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra. This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_000_0050_01C66FA0.C457B290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
You can refer to Section 16.12.1.2 of RFC= =0D 3261.
 
Regards,
Pooja
----- Original Message -----
From:=0D Sudhir
Sent: Wednesday, May 03, 2006 6:29= =0D PM
Subject: [Sip] query regarding BYE= =0D request-URI

Hi All,

If UA received INVITE request with contact and record-route header,= when UA=0D want to built the BYE request.

How BYE request-URI is built? Should I use either record-route or= contact=0D header to construct BYE request-URI?


Any response is appreciated

Thanks in advance
Sudhir

 

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

Tech Mahindra, formerly Mahindra-British Telecom.


Disclaimer:


The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra.


This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
------=_NextPart_000_0050_01C66FA0.C457B290-- --===============1146473048== 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 --===============1146473048==-- From sip-bounces@ietf.org Mon May 08 14:14:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdACe-00062b-A4; Mon, 08 May 2006 14:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdACc-00062O-M3 for sip@ietf.org; Mon, 08 May 2006 14:11:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdACc-0007oW-Jn for sip@ietf.org; Mon, 08 May 2006 14:11:26 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd9yC-0001GY-O3 for sip@ietf.org; Mon, 08 May 2006 13:56:36 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 10:56:31 -0700 Received: from [192.168.1.2] (sjc-vpn-hwcore-52.cisco.com [10.21.152.52]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k48HuPVI017787; Mon, 8 May 2006 10:56:25 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [sip] sip mib - summary of changes due to LC comments Date: Mon, 8 May 2006 10:56:24 -0700 To: "Jean-Francois Mule" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.0 (--) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 proposed resolutions are all fine with me. On May 8, 2006, at 2:42 AM, Jean-Francois Mule wrote: > > Here is a summary of the sip mib changes due to last call comments. > > Let me and Kevin know if we missed anything. A new ID will be =20 > posted on Friday May 12 reflecting those changes unless we hear =20 > anything. > > Jean-Fran=E7ois > > --- Comments #1, #2, #3 from Samir Srivastava > Closed; no changes required. > See http://www1.ietf.org/mail-archive/web/sip/current/msg13855.html > And subsequent emails from Dan and Cullen. > > > --- Comments from Cullen Jennings > See http://www1.ietf.org/mail-archive/web/sip/current/msg13924.html > > --- Comment #4 re: SipTransportProtocol > Closed; > See http://www1.ietf.org/mail-archive/web/sip/current/msg13966.html > New proposed new text: > SipTransportProtocol ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This convention is a bit map. Each bit =20 > represents a > transport protocol. If a bit has value 1, then =20= > that > selected transport protocol is in some way =20 > dependent > on the context of the object using this =20 > convention. > If a bit has value 0, then that transport protocol > is not selected. Combinations of bits can be > set when multiple transport protocols are =20 > selected. > > bit 0 : a protocol other than those defined here. > bit 1 : User Datagram Protocol. > bit 2 : Transmission Control Protocol. > bit 3 : Stream Control Transmission Protocol. > bit 4 : Transport Layer Security Protocol over =20 > TCP. > bit 5 : Transport Layer Security Protocol over =20 > SCTP. > SYNTAX BITS { > other(0), -- none of the following > udp(1), > tcp(2), > sctp(3), -- RFC4168 > tlsTcp(4) > tlsSctp(5) -- RFC 4168 > } > -- REFERENCE "RFC 3261, Section 18" > -- REFERENCE "RFC 4168" > > > --- Comment #5 > Cullen wrote: >> sipMaxTransactions - I really don't know how I would decide what to >> report in most proxies or what an administrator would do with this >> information. Max transaction per second would be a a way that might >> make more sense to me. > I thought it was per second as well but you're right, re-reading =20 > the text, it is not what is meant. > Resolution: change text to reflect that sipMaxTransactions is max =20 > transactions per second. > New text: > sipMaxTransactions OBJECT-TYPE > SYNTAX Unsigned32 (1..4294967295) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the maximum number of =20 > simultaneous > transactions per second that the SIP entity can =20 > handle. > In general the value of this object SHOULD reflect a > level of transaction processing per second that is > considered high enough to impact the systems CPU =20 > and/or > memory resources to the point of deteriorating SIP =20 > call > processing but not high enough to cause catastrophic > system failure." > > > --- Comment #6 > Cullen wrote: >> In sipOptionTagTable, I did not see how the HeaderField stuff =20 >> ended up >> with 0xA0. I imagine this is all right, it was just not obvious to me >> how this all worked. > Resolution: editorial change. > The BITS data type is defined by SMIv2 and folks deal with it =20 > through SNMP agents & tools. But the text in the example could be =20 > more explicit to say, for e.g.: > Example: if a user agent client supports and requires > the server to support reliability of provisional > responses (IETF RFC 3262), this table contains a > row with the option tag string '100rel' in =20 > sipOptionTag > and the OCTET STRING value of '1010 0000' or '0xA0' in > sipOptionTagHeaderField. > -> note: given the example, we will also add an informative =20 > reference to RFC 3262 > > > --- Comment #7 > Cullen wrote: >> It seem that not many people use sipOrganization - do we really want >> this is the mandatory group. > Ok. > Resolution: remove sipOrganization from sipCommonConfigGroup. > > > --- Comment #8 > Cullen wrote: >> Given the many ways that UA determine what the next hop is, the >> sipUACfgServerAddr left me feeling pretty uncomfortable. > Resolution: No changes required. > This table is for *basic* sip ua config and it is basic for sure =20 > yet usable by some of the UA implementation. You can picture a =20 > simple case when a UA is given its registrar server and/or an =20 > outbound sip proxy address. > I poked around using well-known names of SIP UA vendor companies =20 > (soft phone and hard IP phones), and I quickly looked at their SIP =20 > configuration menus and I found the following configurable via soft =20= > menus: > - SIP Proxy (used by some IP phones and soft clients) > - Outbound Proxy > - Register with Proxy: Indicates whether to enable SIP =20 > registration. This parameter is ignored if a SIP proxy server is =20 > not specified. =3D=3D> this would be a case where the Entityrole is =20= > both proxy && registrar. > Arguably, I agree we do not get into how UAs may discover their =20 > registrar, outbound sip proxies or P-CSCFs and things may get more =20 > complicated. But once the discovery mechanism is complete, this =20 > table can be updated by the UA (note that we made this read-only =20 > because of the many ways UAs can discover this or get configured =20 > for this). > > > --- Comment #9 >> On the sipProxyAUthMethod, what do you do if using both TLS and =20 >> Digest. >> TLS often uses Digest at the same time. > Resolution: No changes required. > The MIB object allows this to be expressed: both the TLS and Digest =20= > bits would be turned on (set to '1'). > > > --- Comment #10 >> in sipProxyAuthRealm, the comment about this may need to be stored =20= >> per >> user was concerning. I agree that in some cases it may need to be. >> However, I don't see how this MIB could work when it is per user. Do >> we just say this item is empty or ignored if it is per user? Does the >> MIB work if it is per user and I just don't understand how? > > Agree, this needs to be clarified to have consistent implementations. > Resolution: > - indicate that this object is the *default* realm value used by =20= > the proxy in Proxy-Authenticate headers and, > - add a note to say that in case of per user storage, the =20 > default value is ignored by the proxy. > Proposed new text: > sipProxyAuthRealm OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object reflects the default realm value =20 > used in > Proxy-Authenticate headers. Note that this MAY need > to be stored per user, in which case, this default > value is ignored." > ...snip > > --- Comment #11: >> sipRegAlloowThirdParty - there are two definitions in common usage =20= >> for >> 3rd party reg. This is one of them. However, I don't know of any >> deployment situations that allow this type of 3rd party reg. It is >> the other type that are allowed in practice. Do we need to this at >> all? Do we need to update? > Resolution: add reference to RFC 3261 section 10.2 in description =20 > txt Proposed new text: > sipRegAllowThirdParty OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object reflects whether or not the Registrar > SHOULD allow third party registrations as defined > in RFC 3261 section 10.2. > ...snip > > > --- Comment #12 >> sipUserAuthenticationFailures - when there is a successful >> authentication, does this reset to zero. > No based on the def of Counter32. > Also, based on the semantics of a Counter32 (rfc2578, rfc4181 =20 > section 4.6.1.2), it is not ok to put in the DESCRIPTION clause of =20 > a Counter32/64 that there is a requirement that it MUST reset at =20 > any specific time/event (e.g. here, successful registration). > Also, note that the counter may not be initiated with a creation =20 > value of zero - if we think we need this, we should look at =20 > ZeroBasedCounter32 (rfc2021). > Proposed resolution: by default, no changes. > If folks feel strongly about this, and comment back on the thread, =20 > an alternative could be using ZeroBasedCounter32. > > > --- Comment #13 >> s/Jennins/Jennings/ :-) > Sorry, thank you for catching this. Will be corrected. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 14:52:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAo8-00087l-99; Mon, 08 May 2006 14:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAo7-00087g-36 for sip@ietf.org; Mon, 08 May 2006 14:50:11 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAo3-0001Je-2T for sip@ietf.org; Mon, 08 May 2006 14:50:11 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 May 2006 11:50:07 -0700 X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="1802640566:sNHT29971544" 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 k48InqZ2027172 for ; Mon, 8 May 2006 11:50:06 -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.211); Mon, 8 May 2006 14:50:01 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 14:50:01 -0400 Message-ID: <445F92D9.6000807@cisco.com> Date: Mon, 08 May 2006 14:50: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: 08 May 2006 18:50:01.0701 (UTC) FILETIME=[36560950:01C672D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] ISSUE 1 in Hitchhikers guide to SIP: Whats in, whats out X-BeenThere: sip@ietf.org X-Mailman-Version: 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 preparing to revise the hitchhikers guide to sip (currently at: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt), there are a few open issues it would be good to try and resolve. I'm going to send out a few notes to try and do that. The first and biggest one is around what documents are in scope to be covered by this specification, and which are not. During the meeting, folks pointed out that the absence of SDP and RFC 3264 seemed wrong, and Henry suggested that ICE be included too. The criteria I had defined for this document was that something had to be a literal SIP extension to be included. I think the feedback is that this is too narrow of a definition. Spencer had also commented that MIME objects defined for SIP (like AIB) shouldn't be exlcuded either (they are not SIP extensions). So, I would offer up the following as a proposed scope for inclusion of a document: * Specifies an IETF approved extension to SIP itself * Specifies an IETF approved extension to SDP whose primary purpose is to support SIP * Specifies a MIME object whose primary purpose is to support SIP This would, consequently, expand the scope of the hitchhikers guide to the many SDP extensions. I think thats OK, but folks should be aware of that. Comments or alternatives? 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 May 08 15:06:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB1c-0008SS-8W; Mon, 08 May 2006 15:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdB1b-0008SN-29 for sip@ietf.org; Mon, 08 May 2006 15:04:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdB1a-000202-OL for sip@ietf.org; Mon, 08 May 2006 15:04:07 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 08 May 2006 12:04:06 -0700 X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="273557632:sNHT82650234" 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 k48J44VM018151 for ; Mon, 8 May 2006 12:04:05 -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.211); Mon, 8 May 2006 15:04:05 -0400 Received: from [161.44.55.76] ([161.44.55.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 15:04:05 -0400 Message-ID: <445F9624.6010401@cisco.com> Date: Mon, 08 May 2006 15:04: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2006 19:04:05.0042 (UTC) FILETIME=[2D01A920:01C672D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core 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 One of the categorizations I used for the hitchikers guide were "Core" SIP specifications. THe document says that: > The core SIP specifications represent essential functionality for > almost any implementation. this is somewhat vague. I have in mind a more concrete definition that I think makes more sense. I'd propose: > The core SIP specifications represent the set of specifications whose > functionality is broadly applicable. An extension is broadly > applicable if it fits into one of the following categories: > > * For specifications that impact SIP session management, the > extension would be used for almost every session initiated by a user > agent > > * For specifications that impact SIP registrations, the extension > would be used for almost every registration initiated by a user agent > > * For specifications that impact SIP subscriptions, the extension > would be used for almost every subscription initiated by a user agent > > In other words, these are not specifications that are used just for > some requests and not others; they are specifications that would > apply to each and every request that the extension is relevant for. Based on this definition, I think the following changes would be made to the SIP core specifications: + SDP-new + RFC 3264 + ICE - RFC3323 (doesn't get used in each request!) + RFC 3840 (since the tags are supposed to be used in each registration and in each INVITE and 200 OK) + RFC 3266 (IPv6 in SDP) + RFC 3605 (RTCP attribute in SDP) + RFC 3388 (SDP grouping framework) I debated adding the grouping framework for SDP; since it is getting used broadly for many things I think it is likely to see usage in nearly every SDP, so I put it in the list. Do people concur with this definition and the resulting specifications listed in the core set? 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 May 08 15:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBjv-0006uN-N3; Mon, 08 May 2006 15:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBju-0006uI-RG for sip@ietf.org; Mon, 08 May 2006 15:49:54 -0400 Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBjt-0004CG-Hr for sip@ietf.org; Mon, 08 May 2006 15:49:54 -0400 Received: (qmail 8706 invoked by uid 510); 8 May 2006 15:22:59 -0400 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.176):. Processed in 0.949634 secs); 08 May 2006 19:22:59 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.176):. Processed in 0.949634 secs Process 8701) Received: from c-24-1-142-176.hsd1.tx.comcast.net (HELO DSX400) (henry@pulver.com@24.1.142.176) by 192.246.69.184 with SMTP; Mon, 08 May 2006 19:22:58 +0000 From: "Henry Sinnreich" To: "'Jonathan Rosenberg'" , "'IETF SIP List'" Subject: RE: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core SIP Date: Mon, 8 May 2006 14:49:44 -0500 Organization: pulver.com Message-ID: <001701c672d8$8e475620$2800a8c0@DSX400> 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: <445F9624.6010401@cisco.com> Thread-Index: AcZyzqQuCfuaO8r5Ru+BHY5QPJ6OSwACcIgw X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for adding ICE. Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Monday, May 08, 2006 2:04 PM To: IETF SIP List Subject: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core SIP One of the categorizations I used for the hitchikers guide were "Core" SIP specifications. THe document says that: > The core SIP specifications represent essential functionality for > almost any implementation. this is somewhat vague. I have in mind a more concrete definition that I think makes more sense. I'd propose: > The core SIP specifications represent the set of specifications whose > functionality is broadly applicable. An extension is broadly > applicable if it fits into one of the following categories: > > * For specifications that impact SIP session management, the > extension would be used for almost every session initiated by a user > agent > > * For specifications that impact SIP registrations, the extension > would be used for almost every registration initiated by a user agent > > * For specifications that impact SIP subscriptions, the extension > would be used for almost every subscription initiated by a user agent > > In other words, these are not specifications that are used just for > some requests and not others; they are specifications that would > apply to each and every request that the extension is relevant for. Based on this definition, I think the following changes would be made to the SIP core specifications: + SDP-new + RFC 3264 + ICE - RFC3323 (doesn't get used in each request!) + RFC 3840 (since the tags are supposed to be used in each registration and in each INVITE and 200 OK) + RFC 3266 (IPv6 in SDP) + RFC 3605 (RTCP attribute in SDP) + RFC 3388 (SDP grouping framework) I debated adding the grouping framework for SDP; since it is getting used broadly for many things I think it is likely to see usage in nearly every SDP, so I put it in the list. Do people concur with this definition and the resulting specifications listed in the core set? 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 Mon May 08 16:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBvQ-0001bZ-RS; Mon, 08 May 2006 16:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBvP-0001bO-IE for sip@ietf.org; Mon, 08 May 2006 16:01:47 -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 1FdBvO-0005JR-6H for sip@ietf.org; Mon, 08 May 2006 16:01:47 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 May 2006 13:01:46 -0700 X-IronPort-AV: i="4.05,102,1146466800"; d="scan'208"; a="426806278:sNHT31455136" 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 k48K1jw1023546; Mon, 8 May 2006 13:01:45 -0700 (PDT) Received: from [10.32.245.158] (stealth-10-32-245-158.cisco.com [10.32.245.158]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id k48Jxm93001932; Mon, 8 May 2006 12:59:48 -0700 In-Reply-To: <445F9624.6010401@cisco.com> References: <445F9624.6010401@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68FF84A8-A6F9-4BE6-92C8-720F9B57525D@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core SIP Date: Mon, 8 May 2006 16:01:22 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.749.3) DKIM-Signature: a=rsa-sha1; q=dns; l=3634; t=1147118389; x=1147982389; c=relaxed/simple; s=oregon; h=To: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]=20ISSUE=202=20in=20Hitchhikers=20guide=20to=20SIP=3A=20Wha t=20constitutes=20Core=20SIP |To:Jonathan=20Rosenberg=20; X=v=3Dcisco.com=3B=20h=3DVNEbQTPKPrzUfk5UZHj5SGmXrRg=3D; b=Wutc/vxl000bxa4FBpsUuv/CyPB3ZCN+nm+H8AXrG3/u8y6SW+4xRifoc5K5E/K+rEV73rB9 AIt9OGeRBY0+dtEcGqjnk32Jdy6014P/8JNop/OKe9BdDQzBrAxIIaAG; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 From the peanut gallery: Rather than suck everything that touches SIP into its gravity well (TLS, DNS) or conversely leave something out that you really need in order to understand the unified field theory of SIP, let me suggest a compromise: where there is a convenient grouping of things independent of SIP itself, introduce a level of indirection. Then let somebody else write a specification for that area. One obvious candidate here is to pull out everything having to do with NAT traversal (STUN, ICE, RFC3605, etc) and let somebody write that up separately. By analogy, that's treating the Hitchhiker's Guide to SIP as the Newtonian physics part, and NAT traversal as the part you need to use when space and time are warped (or even contain naked singularities, which NATs are somewhat akin to :-). Just a thought to keep this from becoming too unwieldy and a maintenance nightmare... Dave. On May 8, 2006, at 3:04 PM, Jonathan Rosenberg wrote: > One of the categorizations I used for the hitchikers guide were "Core" > SIP specifications. THe document says that: > >> The core SIP specifications represent essential functionality for >> almost any implementation. > > this is somewhat vague. I have in mind a more concrete definition > that I > think makes more sense. I'd propose: > >> The core SIP specifications represent the set of specifications whose >> functionality is broadly applicable. An extension is broadly >> applicable if it fits into one of the following categories: >> * For specifications that impact SIP session management, the >> extension would be used for almost every session initiated by a user >> agent >> * For specifications that impact SIP registrations, the extension >> would be used for almost every registration initiated by a user agent >> * For specifications that impact SIP subscriptions, the extension >> would be used for almost every subscription initiated by a user agent >> In other words, these are not specifications that are used just for >> some requests and not others; they are specifications that would >> apply to each and every request that the extension is relevant for. > > > Based on this definition, I think the following changes would be > made to the SIP core specifications: > > + SDP-new > + RFC 3264 > + ICE > - RFC3323 (doesn't get used in each request!) > + RFC 3840 (since the tags are supposed to be used in each > registration and in each INVITE and 200 OK) > + RFC 3266 (IPv6 in SDP) > + RFC 3605 (RTCP attribute in SDP) > + RFC 3388 (SDP grouping framework) > > I debated adding the grouping framework for SDP; since it is > getting used broadly for many things I think it is likely to see > usage in nearly every SDP, so I put it in the list. > > Do people concur with this definition and the resulting > specifications listed in the core set? > > 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 Mon May 08 16:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdC3o-0008Mx-W2; Mon, 08 May 2006 16:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdC3m-0008Go-Uy for sip@ietf.org; Mon, 08 May 2006 16:10:26 -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 1FdC3m-0005hR-1M for sip@ietf.org; Mon, 08 May 2006 16:10:26 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYY00601QPVF6@siemenscomms.co.uk> for sip@ietf.org; Mon, 08 May 2006 21:10:44 +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 <0IYY002B0QPVOA@siemenscomms.co.uk>; Mon, 08 May 2006 21:10:43 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 08 May 2006 21:10:14 +0100 Content-return: allowed Date: Mon, 08 May 2006 21:10:13 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Christer Holmberg (JO/LMF)" , Hisham Khartabil Message-id: <50B1CBA96870A34799A506B2313F266708DDAB3B@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 847361531d5cb2b89126844012e81b58 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 Christer, The main thrust of the connected-identity draft is providing an authenticated connected identity. We have no mechanism for providing an authenticated response identity, and an unauthenticated response = identity doesn't really fit with the rest of the draft and, in some people's = opinion, is not worthwhile. I must refer you again to Jon Peterson's email of = 5th April for a bunch of reasons why response identity is not viable. If = you wish to challenge that, I still think it would be more appropriate to = put forward your proposals in a separate draft, or at least reply to the = points made in that email. John > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 08 May 2006 16:34 > To: Hisham Khartabil > Cc: sip@ietf.org; Elwell, John > Subject: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 >=20 > Hi,=20 >=20 > >I agree with you that the argument that there is a hint in=20 > RFC3261 is not really an argument for not considering changing=20 > >the To header in a SIP response. The real argument that John=20 > did mention is that there is no mechanism for asserting a=20 > >response identity. >=20 > I don't think we have a requirement to assert the identity in=20 > a response.=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On May 8, 2006, at 2:21 PM, Christer Holmberg ((JO/LMF)) wrote: >=20 > > > > Hi, > > > >> I don't agree that discussion has shown that there is no harm in=20 > >> changing the To header field URI in a response. There is no=20 > >> forewarning of this in RFC3261. > > > > I don't follow. Do you mean that we, in a current spec,=20 > need to "warn"=20 > > people about what will be changed/added in future=20 > revisions, and that=20 > > we are only allowed to do things in revision we have=20 > "warned" about in=20 > > earlier versions ?????? In most cases changes are done in revisions = > > because issues have been identified AFTER the previous version has=20 > > been released... > > > > And, EVEN if the current spec "warn" about something, that=20 > alone can=20 > > not be reason enough to say that it will cause no harm. If=20 > you expect=20 > > implementations to support something it shall be normative=20 > text - NOT=20 > > "hints" about what may happen in the future... > > > >> Even though we could use an option tag to ensure that a UA is=20 > >> compliant, we can anticipate problems with proxies. I=20 > repeat that we=20 > >> need a separate I-D to discuss such issues. > > > > I think the discussion has showed that there will be no=20 > problems with=20 > > proxies. > > > > The only argument I've heard is that it would mess up the=20 > transaction=20 > > logic, but we have shown that is not the case. > > > > Regards, > > > > Christer > > > > > > > >> -----Original Message----- > >> From: Jesske, R [mailto:R.Jesske@t-com.net] > >> Sent: 08 May 2006 11:53 > >> To: christer.holmberg@ericsson.com; Elwell, John;=20 > jbemmel@zonnet.nl;=20 > >> sip@ietf.org > >> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > >> Subject: AW: [Sip] Issue 1 in=20 > >> draft-ietf-sip-connected-identity-00.txt > >> > >> Hi, > >> As Christer said, I don't know if this is a straight way=20 > forward to=20 > >> wait for an further document describing the other way around. > >> We (seen from TISPAN purpose) have a requirement of an additional = > >> connected identity in the response and that can be fulfilled by=20 > >> changing the to header in the response. > >> The discussion showed it that there is no harm in changing the to=20 > >> header field in a response. > >> Why don't do it? > >> > >> Best Regards > >> > >> Roland > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Christer Holmberg (JO/LMF) > >>> [mailto:christer.holmberg@ericsson.com] > >>> Gesendet: Montag, 8. Mai 2006 11:12 > >>> An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > >>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > >>> Betreff: RE: [Sip] Issue 1 in > >> draft-ietf-sip-connected-identity-00.txt > >>> > >>> > >>> > >>> Hi, > >>> > >>>> You are correct that it does not necessarily prevent us > >>> changing the URI in a response in a "subsequent revision", but > >>>> that is a different discussion from the discussion we have > >>> already had and concluded on mid-dialog requests. > >>> > >>> I thought we now also have had a discussion about the=20 > responses, and=20 > >>> agreed that it from a pure protocol logic perspective=20 > would cause no=20 > >>> harm. > >>> > >>>> As I said before to Roland, if there is interest in doing > >>> this it should be addressed in a separate I-D giving the > >>>> background, requirements, mechanism, etc. > >>> > >>> Of course it can be done that way. But, isn't the issue=20 > that we then=20 > >>> may end up with two mechanisms of doing the same way > >>> - the "request way" described in the connected identity=20 > draft, and=20 > >>> the "response way" to be described in another draft? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Christer Holmberg (JO/LMF) > >>>> [mailto:christer.holmberg@ericsson.com] > >>>> Sent: 05 May 2006 08:39 > >>>> To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > >>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > >>>> Subject: RE: [Sip] Issue 1 in > >>> draft-ietf-sip-connected-identity-00.txt > >>>> > >>>> > >>>> Hi, > >>>> > >>>>> RFC3261 Section 12.2.1.1: "[...] It is expected that > >>>> mandatory reflection of the original To and From URI in > >> mid-dialog > >>>> requests will be deprecated in a > >>>>> subsequent revision of this specification." > >>>> > >>>> Ok, I appologize for missing that. > >>>> > >>>> However, that doesn't prevent us from also allowing to > >>> change the URI > >>>> in responses in a "subsequence revision". > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> From: "Christer Holmberg (JO/LMF)" > >> > >>>> To: "Elwell, John" ; "Jesske, R" > >>>> ; > >>>> Cc: ; > >>>> Sent: Friday, May 05, 2006 9:22 AM > >>>> Subject: RE: [Sip] Issue 1 in > >>> draft-ietf-sip-connected-identity-00.txt > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>>> Technically it might work, but RFC3261 neither gives > >>>> permission to change > >>>>> the To header field URI in a response nor hints at a future > >>>> lifting of this > >>>>> restriction. > >>>> > >>>> So, where does RFC3261 give permisson to change the To > >> header field > >>>> URI later in a request, then??? > >>>> > >>>> I thought the changing of the URI was something that THIS > >> GROUP has > >>>> agreed is to be allowed. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Christer Holmberg (JO/LMF) > >>>>> [mailto:christer.holmberg@ericsson.com] > >>>>> Sent: 04 May 2006 21:55 > >>>>> To: Elwell, John; Jesske, R; sip@ietf.org > >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > >>>>> Subject: RE: [Sip] Issue 1 in > >>>> draft-ietf-sip-connected-identity-00.txt > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> From the safeness point of view, I thought we already > >>>> agreed (at least > >>>>> I haven't heard any disagreement) that doing it would not > >>> be unsafe, > >>>>> since the arguments that modifying the To and/or From > >>>> header URI would > >>>>> affect the transaction logic were not true. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>>> Sent: 4. toukokuuta 2006 13:39 > >>>>> To: Jesske, R; sip@ietf.org > >>>>> Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > >>>>> Subject: RE: [Sip] Issue 1 in > >>>> draft-ietf-sip-connected-identity-00.txt > >>>>> > >>>>> Roland, > >>>>> > >>>>> Well, you would need to convince the community that this is a=20 > >>>>> worthwhile and safe thing to do. Agreement to date is > >>> only to change > >>>>> From and To header field URIs in mid-dialog requests. > >>>>> Changing the To header field URI in a response would > >>>> require separate > >>>>> agreement. I suggest you write an I-D and try to get > >>>> backing. However, > >>>>> I fear you will encounter strong opposition. > >>>>> > >>>>> Regards, > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Jesske, R [mailto:R.Jesske@t-com.net] > >>>>>> Sent: 04 May 2006 09:37 > >>>>>> To: Elwell, John; sip@ietf.org > >>>>>> Cc: chister.holmberg@ericsson.com;=20 > >>>>>> sebastien.garcin@francetelecom.com; Alexeitsev, D; > >>>>> esasaki@NTT-AT.COM > >>>>>> Subject: AW: [Sip] Issue 1 in > >>>>> draft-ietf-sip-connected-identity-00.txt > >>>>>> > >>>>>> Dear John et all, > >>>>>> I'm sorry to go again into the opposite oppinion but > >>> I'm still in > >>>>>> favour of enhancing the draft to provide identity in > >>> the To header > >>>>>> field URI of a response. > >>>>>> > >>>>>> I don't know if we have to rediscuss all the > >> possibilities and > >>>>>> assumptions. But fact is that such a to header change would > >>>>> be useful > >>>>>> for some services. > >>>>>> > >>>>>> Best Regards > >>>>>> > >>>>>> Roland > >>>>>> > >>>>>> > >>>>>>> -----Urspr=FCngliche Nachricht----- > >>>>>>> Von: Elwell, John [mailto:john.elwell@siemens.com] > >>>>>>> Gesendet: Dienstag, 2. Mai 2006 22:20 > >>>>>>> An: sip@ietf.org > >>>>>>> Betreff: [Sip] Issue 1 in > >>>> draft-ietf-sip-connected-identity-00.txt > >>>>>>> > >>>>>>> > >>>>>>> There are three open issues in this draft and a fourth that > >>>>>> was raised > >>>>>>> subsequently. This mail initiates discussion on the first > >>>>> issue. I > >>>>>>> will initiate discussion on the other three issues in > >>> separate > >>>>>>> mails. > >>>>>>> > >>>>>>> Issue 1 appears in section 5 and concerns the fact that > >>>>> this draft > >>>>>>> intentionally does not address response identity, and > >>>>> therefore the > >>>>>>> identity of a dialog-forming responder to an INVITE > >>> request is > >>>>>>> conveyed in a separate request (e.g., UPDATE) in > >> the reverse > >>>>>>> direction rather than in the response to the INVITE > >>> request. The > >>>>>>> open issue is stated as: > >>>>>>> > >>>>>>> "OPEN ISSUE. Should this be extended to allow a > >>>>> URI in the To > >>>>>>> header field of a response to change compared with > >>>>>> the To header > >>>>>>> field in a request? This could convey a connected > >>>>>> identity in a > >>>>>>> response to an INVITE request, but it would not be=20 > >>>>>>> authenticated. > >>>>>>> Authentication would have to rely on transitive > >>>>> trust, which > >>>>>>> might > >>>>>>> be feasible in a closed environment where the sips > >>>>>> URI scheme is > >>>>>>> used." > >>>>>>> > >>>>>>> There was considerable list discussion on this shortly after > >>>>>>> IETF65 with no > >>>>>>> resolution. I won't attempt to summarise it. My opinion > >>>>>> (for what it's > >>>>>>> worth) is as follows. > >>>>>>> > >>>>>>> 1. Whereas RFC 3261 anticipates deprecating fixed > >>> To/From header > >>>>>>> field URIs throughout a dialog (i.e., it anticipates that > >>>>> these will > >>>>>>> be allowed to change mid-dialog), it says nothing to > >>> warn of any > >>>>>>> future removal of the requirement that the To header > >>>> field URI in > >>>>>>> the response be the same as that in the request. > >>>>> Therefore I believe > >>>>>>> it would be dangerous to specify such a change to the > >>> To header > >>>>>>> field URI. > >>>>>>> > >>>>>>> 2. The prime motivation for this draft was to provide > >>>>> authenticated > >>>>>>> identity, i.e., to complement the sip-identity draft. An > >>>>> identity in > >>>>>>> the To header field of a response cannot be > >>> authenticated, for > >>>>>>> reasons stated many times on this list and at meetings. > >>>>> Therefore, > >>>>>>> at least in the Internet, a response identity would > >>> have little > >>>>>>> value. > >>>>>>> > >>>>>>> 3. A comprehensive list of reasons for not going down > >>>>> that path were > >>>>>>> given by Jon Peterson (editor of the Identity draft) in a > >>>>> message to > >>>>>>> this list on 5th April. > >>>>>>> > >>>>>>> 4. In closed environments an unauthenticated response > >>>>> identity might > >>>>>>> have some value. But this could be achieved using > >>>>>> P-Asserted-Identity, say, > >>>>>>> rather than bending the rules for To headers in responses. > >>>>>>> > >>>>>>> Therefore I am NOT in favour of enhancing the draft > >>> to provide > >>>>>>> identity in the To header field URI of a response. Can > >>>>> people agree > >>>>>>> to this resolution of the issue? > >>>>>>> > >>>>>>> John > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Internet-Drafts@ietf.org > >>>> [mailto:Internet-Drafts@ietf.org] > >>>>>>>> Sent: 26 April 2006 20:50 > >>>>>>>> To: i-d-announce@ietf.org > >>>>>>>> Cc: sip@ietf.org > >>>>>>>> Subject: [Sip] I-D > >>>>> ACTION:draft-ietf-sip-connected-identity-00.txt > >>>>>>>> > >>>>>>>> A New Internet-Draft is available from the on-line > >>>>> Internet-Drafts > >>>>>>>> directories. > >>>>>>>> This draft is a work item of the Session Initiation > >>> Protocol > >>>>>>>> Working Group of the IETF. > >>>>>>>> > >>>>>>>> Title : Connected Identity in the Session > >>> Initiation Protocol > >>>>>>>> (SIP) > >>>>>>>> Author(s) : J. Elwell > >>>>>>>> Filename : > >>>>> draft-ietf-sip-connected-identity-00.txt > >>>>>>>> Pages : 20 > >>>>>>>> Date : 2006-4-26 > >>>>>>>> > >>>>>>>> Because of retargeting of a Session Initiation Protocol > >>>>>>>> (SIP) dialog- > >>>>>>>> forming request, the UAS can have a different identity > >>>>>>> from that in > >>>>>>>> the To header. This document provides a means for > >>>>> that 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 PSTN > >>>>>>>> behind a gateway. This document normatively > >> updates RFC > >>>>>>>> 3261 (SIP). > >>>>>>>> This work is being discussed on the sip@ietf.org > >>>>> mailing list. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> A URL for this Internet-Draft is: > >>>>>>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > >>>>>>>> dentity-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=20 > >>>>>>>> draft-ietf-sip-connected-identity-00.txt". > >>>>>>>> > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> 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-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=20 > >>>>>>>> "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=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 = > >>> sipping@ietf.org for new developments on the application 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 >=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 May 08 16:25:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCGL-0002OY-Fz; Mon, 08 May 2006 16:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCGJ-0002OT-PI for sip@ietf.org; Mon, 08 May 2006 16:23: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 1FdCGI-00069x-GI for sip@ietf.org; Mon, 08 May 2006 16:23:23 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IYY00901RBQR9@siemenscomms.co.uk> for sip@ietf.org; Mon, 08 May 2006 21:23:50 +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 <0IYY00667RBQVA@siemenscomms.co.uk>; Mon, 08 May 2006 21:23:50 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 08 May 2006 21:23:21 +0100 Content-return: allowed Date: Mon, 08 May 2006 21:23:20 +0100 From: "Elwell, John" Subject: RE: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes C ore SIP To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266708DDAB43@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: e1e48a527f609d1be2bc8d8a70eb76cb 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, > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 08 May 2006 20:04 > To: IETF SIP List > Subject: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What > constitutes Core SIP > > One of the categorizations I used for the hitchikers guide were "Core" > SIP specifications. THe document says that: > > > The core SIP specifications represent essential functionality for > > almost any implementation. > > this is somewhat vague. I have in mind a more concrete > definition that I > think makes more sense. I'd propose: > > > The core SIP specifications represent the set of > specifications whose > > functionality is broadly applicable. An extension is broadly > > applicable if it fits into one of the following categories: > > > > * For specifications that impact SIP session management, the > > extension would be used for almost every session initiated by a user > > agent > > > > * For specifications that impact SIP registrations, the extension > > would be used for almost every registration initiated by a > user agent > > > > * For specifications that impact SIP subscriptions, the extension > > would be used for almost every subscription initiated by a > user agent [JRE] I didn't notice anything that fell into this category and I have a hard time thinking of something that might (unless you use this to justify including RFC3265). 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 Mon May 08 16:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCLt-0006mP-IF; Mon, 08 May 2006 16:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdCLs-0006mK-5V for sip@ietf.org; Mon, 08 May 2006 16:29:08 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdCLr-0006WT-UH for sip@ietf.org; Mon, 08 May 2006 16:29:08 -0400 Received: by py-out-1112.google.com with SMTP id n25so1661927pyg for ; Mon, 08 May 2006 13:29: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=cekFpLD3LUumG1bnphqfjlj4OMadnYeX2+q0koYB9+5kqpHq8vMdx9RImkl5UaPvZU1YLp7ph6UTPkGhNwYlTnIyKAPolD6wPy+7GEVQJd6mtPeL+U9W5x6t00cnNpvC2pDYahPr7PvYXXUml84Sn/wMyE242oG16hzJ/8F1pfs= Received: by 10.35.82.15 with SMTP id j15mr608294pyl; Mon, 08 May 2006 13:29:07 -0700 (PDT) Received: by 10.35.54.17 with HTTP; Mon, 8 May 2006 13:29:07 -0700 (PDT) Message-ID: <953beacc0605081329u791ea7acw9f1a968033ec9f4c@mail.gmail.com> Date: Mon, 8 May 2006 13:29:07 -0700 From: "Rohan Mahy" To: "Jean-Francois Mule" Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , Michael Procter , "Kevin Lingle \(klingle\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 fine with the proposed resolution, I think we are better off removing this object entirely. I don't think the use case for setting or checking if one version of 3rd party registration is allowed using a MIB is well motivated. thanks, -rohan On 5/8/06, Jean-Francois Mule wrote: > Ok, works for me. We will just add a citation to RFC3261 in the object > description to make it clearer (we will also keep the existing REFERENCE > clause for that object). > > Jean-Francois. > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Sunday, May 07, 2006 11:49 AM > > To: Jean-Francois Mule > > Cc: Michael Procter; Kevin Lingle (klingle); sip@ietf.org; Romascanu, > > Dan (Dan); Juergen Schoenwaelder > > Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip- > > mib comments) > > > > > > How about update the description to be 100% clear what type it is. I > > really think we only need to deal with the type defined in RFC 3261 - > > future things could do more. I think the current description is the > > type defined in 3261. The text below might works as an update but > > perhaps someone has better text. > > > > Old > > >> DESCRIPTION > > >> "This object reflects whether or not the Registrar > > >> SHOULD allow third party registrations. In third-party > > >> registration, the entity issuing the request (in the > > >> From header) is different from the entity being > > >> registered (in the To header) to whom the provided > > >> Contact information applies. > > > > New > > >> DESCRIPTION > > >> "This object reflects whether or not the Registrar > > >> SHOULD allow third party registrations as defined in > > >> Section 10.2 of RFC 3261. > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > >> In third-party > > >> registration, the entity issuing the request (in the > > >> From header) is different from the entity being > > >> registered (in the To header) to whom the provided > > >> Contact information applies. > > > > PS - From an AD point of view, I am OK with no change on this. I > > think it is relatively clear that it is the To From type and this is > > the only type defined in 3261 so I think it will be 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 08 18:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdETD-0003mb-Iw; Mon, 08 May 2006 18:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdETC-0003mW-58 for sip@ietf.org; Mon, 08 May 2006 18:44:50 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdET9-0005qB-Qq for sip@ietf.org; Mon, 08 May 2006 18:44:50 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k48MjjnP027897 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 8 May 2006 17:45:46 -0500 In-Reply-To: <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> References: <445F3CF3.5000506@motorola.com> <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19BBD41F-0902-43D4-87FA-25D1AF95E83F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Answer Mode Date: Mon, 8 May 2006 17:44:40 -0500 To: ac2491@cs.columbia.edu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 May 8, 2006, at 10:46 AM, ac2491@cs.columbia.edu wrote: > Hi Preeti, > > For my aplication I used Answer-mode as auto and appropriately > handled SIP > signalling (draft should suggest usage). If it was not auto > application > defaulted to manual (SIP signalling for manual ie human > intervention (pick > up phone) for call setup). > If you'd like to send some text suggesting usage, it can probably be incorporated. Personally I though the draft was already fairly clear here, but it must not be (given the questions), so let's fix it. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 09 01:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKSo-0008OS-Dy; Tue, 09 May 2006 01:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKSm-0008ON-BX for sip@ietf.org; Tue, 09 May 2006 01:08:48 -0400 Received: from nz-out-0102.google.com ([64.233.162.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdKSl-0001E5-4m for sip@ietf.org; Tue, 09 May 2006 01:08:48 -0400 Received: by nz-out-0102.google.com with SMTP id i11so1335467nzi for ; Mon, 08 May 2006 22:08:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YGQ8tAG7wcyxCnTFvfqXSM8lAaSGl08yA4co0TIA0Nq+c/BvrBzbtubdouAYNH18EF/soP7M5wsw3IJhXiLuwv/H3VOXgm8kMbNlHmIUUuoAOHTdOadq1XKZvj3OrqWgbuPKjEA4TLKVqHXTvz5oc3w5mCcUQOEdh3/niGzAwco= Received: by 10.64.53.8 with SMTP id b8mr1497573qba; Mon, 08 May 2006 22:08:46 -0700 (PDT) Received: by 10.65.155.9 with HTTP; Mon, 8 May 2006 22:08:46 -0700 (PDT) Message-ID: <296966940605082208q26313650kcfc97f778303c3eb@mail.gmail.com> Date: Mon, 8 May 2006 23:08:46 -0600 From: "Alan Hawrylyshen" To: "Jonathan Rosenberg" Subject: Re: [Sip] ISSUE 1 in Hitchhikers guide to SIP: Whats in, whats out In-Reply-To: <445F92D9.6000807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <445F92D9.6000807@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahawrylyshen@ditechcom.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On 5/8/06, Jonathan Rosenberg wrote: > This would, consequently, expand the scope of the hitchhikers guide to > the many SDP extensions. I think thats OK, but folks should be aware of > that. Although it will expand the document significantly, it also collects a significant and useful body of work in one place (or at least pointers thereto). If you feel this undertaking is tractable, it is likely effory well-spent. It MAY cause you to want to take on more editing assistance though. Alan -- a d o t h a w r y l y s h e n a t g m a i l d o t c o m _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 09 04:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNsH-0004WB-Qo; Tue, 09 May 2006 04:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNsF-0004Ox-TS for sip@ietf.org; Tue, 09 May 2006 04:47:19 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdNsE-0003Lo-IY for sip@ietf.org; Tue, 09 May 2006 04:47:19 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k498lDOl026863; Tue, 9 May 2006 02:47:13 -0600 (MDT) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Tue, 9 May 2006 02:47:13 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcZy3hFQcYDqr8bKSmCiC7Ra+sDv1QAYg1Lg From: "Jean-Francois Mule" To: "Rohan Mahy" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org, "Romascanu, Dan \(Dan\)" , "Kevin Lingle \(klingle\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Thank you for your review and comment. You wrote: > Hi, >=20 > While I am fine with the proposed resolution, I think we are better > off removing this object entirely. =20 > I don't think the use case for > setting or checking if one version of 3rd party registration is > allowed using a MIB is well motivated. This is a protocol MIB and the typical way folks build these management = objects (be it with SMI or XML or any other notation syntax or language) = is by walking through the protocol text and looking at the things that = can be modeled for management, configured, monitored, etc. What pops up from a walk-through of RFC 3261 section 10 seems to justify = this object for a registrar (I think) and may motivate a *basic* use = case for an on/off switch.=20 If it is true that the 3rd party mechanism intended and defined by 3261 = is used by some implementations as we read in the thread, even if the = best current practices for allowing/disallowing 3rd party reg have = evolved, this object could be set by the registrar. - from 3261, section 10.2 and 10.3 In architectures that support third-party registration, one ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ entity may be responsible for updating the registrations associated with multiple addresses-of-record. -> This means some do, some don't. - from section 26.1.1 While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf. ^^^^^^^^^^^^ So at a first level, one can view the origin of this object and the = basis use case. The question becomes: Is it a given that 3rd-party registration is supported by registrar = implementations?=20 If so, do implementers typically expose the controls for = enabling/disabling 3rd-party reg to end-users or operators?=20 If the answers are yes to both, this object has a valid case. If not, I agree, it should be deleted. =20 Finally, looking at the current uses of 3rd-party reg, if folks believe = it is better to just remove it, this is certainly fine with me. Thoughts? Jean-Fran=E7ois >=20 > thanks, > -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 09 05:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdO6v-00027T-8M; Tue, 09 May 2006 05:02:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdO6t-00027O-9T for sip@ietf.org; Tue, 09 May 2006 05:02:27 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdO6s-0004HM-RR for sip@ietf.org; Tue, 09 May 2006 05:02:27 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4992KMq019808; Tue, 9 May 2006 12:02:24 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 12:02:21 +0300 Received: from [127.0.0.1] ([172.21.35.179]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 May 2006 12:02:21 +0300 Message-ID: <44605A9C.2070605@nokia.com> Date: Tue, 09 May 2006 12:02:20 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What constitutes Core SIP References: <445F9624.6010401@cisco.com> In-Reply-To: <445F9624.6010401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 09:02:21.0285 (UTC) FILETIME=[47E74950:01C67347] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: Notice that RFC 3266 has been included in the base SDP-new. Essentially, RFC 2327 + RFC 3266 (+some-bug-fixes) = SDP-new. So you don't need RFC 3266. /Miguel Jonathan Rosenberg wrote: > One of the categorizations I used for the hitchikers guide were "Core" > SIP specifications. THe document says that: > >> The core SIP specifications represent essential functionality for >> almost any implementation. > > this is somewhat vague. I have in mind a more concrete definition that I > think makes more sense. I'd propose: > >> The core SIP specifications represent the set of specifications whose >> functionality is broadly applicable. An extension is broadly >> applicable if it fits into one of the following categories: >> >> * For specifications that impact SIP session management, the >> extension would be used for almost every session initiated by a user >> agent >> >> * For specifications that impact SIP registrations, the extension >> would be used for almost every registration initiated by a user agent >> >> * For specifications that impact SIP subscriptions, the extension >> would be used for almost every subscription initiated by a user agent >> >> In other words, these are not specifications that are used just for >> some requests and not others; they are specifications that would >> apply to each and every request that the extension is relevant for. > > > Based on this definition, I think the following changes would be made to > the SIP core specifications: > > + SDP-new > + RFC 3264 > + ICE > - RFC3323 (doesn't get used in each request!) > + RFC 3840 (since the tags are supposed to be used in each registration > and in each INVITE and 200 OK) > + RFC 3266 (IPv6 in SDP) > + RFC 3605 (RTCP attribute in SDP) > + RFC 3388 (SDP grouping framework) > > I debated adding the grouping framework for SDP; since it is getting > used broadly for many things I think it is likely to see usage in nearly > every SDP, so I put it in the list. > > Do people concur with this definition and the resulting specifications > listed in the core set? > > Thanks, > Jonathan R. > > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 09 05:54:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOrz-0004tP-E0; Tue, 09 May 2006 05:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdOry-0004so-99 for sip@ietf.org; Tue, 09 May 2006 05:51:06 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdOrx-0006fb-2x for sip@ietf.org; Tue, 09 May 2006 05:51:06 -0400 Received: from hydra.cs.columbia.edu (IDENT:q7wLic0c2puvmOfs2Zyr8TB6d0PjBEfU@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k499lpX6006852 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 9 May 2006 05:51:02 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:D8okFthY8yOSOSbGYxSdYGcW4wGQfdKV@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id k499loIL004725; Tue, 9 May 2006 05:47:50 -0400 Received: from 24.199.99.149 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Tue, 9 May 2006 05:47:51 -0400 (EDT) Message-ID: <32857.24.199.99.149.1147168071.squirrel@webmail.cs.columbia.edu> In-Reply-To: <19BBD41F-0902-43D4-87FA-25D1AF95E83F@softarmor.com> References: <445F3CF3.5000506@motorola.com> <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> <19BBD41F-0902-43D4-87FA-25D1AF95E83F@softarmor.com> Date: Tue, 9 May 2006 05:47:51 -0400 (EDT) Subject: Re: [Sip] Answer Mode From: ac2491@cs.columbia.edu To: "Dean Willis" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.7 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, Was just pointing out the usages given in the drarf ;-) -Anurag > > On May 8, 2006, at 10:46 AM, ac2491@cs.columbia.edu wrote: > >> Hi Preeti, >> >> For my aplication I used Answer-mode as auto and appropriately >> handled SIP >> signalling (draft should suggest usage). If it was not auto >> application >> defaulted to manual (SIP signalling for manual ie human >> intervention (pick >> up phone) for call setup). >> > > If you'd like to send some text suggesting usage, it can probably be > incorporated. Personally I though the draft was already fairly clear > here, but it must not be (given the questions), so let's fix it. > > -- > Dean > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 09 13:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdW9G-0000C0-4i; Tue, 09 May 2006 13:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdW9E-0000Bv-Im for sip@ietf.org; Tue, 09 May 2006 13:37:24 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FdW9B-0003u3-UD for sip@ietf.org; Tue, 09 May 2006 13:37:24 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1147196154!8323178!42 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1052 invoked from network); 9 May 2006 17:37:20 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 9 May 2006 17:37:20 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE00215B22; Tue, 9 May 2006 13:37:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Tue, 9 May 2006 12:37:17 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C69A@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <31529C1D0F94F24989CBC1BCDF3C04970818BE54@S4DE8PSAAGT.blf.telekom.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt thread-index: AcZyjhVHWdj7gwyIRYaWmlNFIlb4bgBAPnRQ From: "Dolly, Martin C, ALABS" To: "Jesske, R" , , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Hello, We have a similar need in ATIS. I support what Roland/TISPAN is = proposing. Cheers, Martin=20 -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net]=20 Sent: Monday, May 08, 2006 6:53 AM To: christer.holmberg@ericsson.com; john.elwell@siemens.com; = jbemmel@zonnet.nl; sip@ietf.org Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Hi, As Christer said, I don't know if this is a straight way forward to wait = for an further document describing the other way around. We (seen from TISPAN purpose) have a requirement of an additional = connected identity in the response and that can be fulfilled by changing = the to header in the response.=20 The discussion showed it that there is no harm in changing the to header = field in a response. Why don't do it? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Gesendet: Montag, 8. Mai 2006 11:12 > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Betreff: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt >=20 >=20 >=20 > Hi,=20 >=20 > >You are correct that it does not necessarily prevent us=20 > changing the URI in a response in a "subsequent revision", but=20 > >that is a different discussion from the discussion we have=20 > already had and concluded on mid-dialog requests. >=20 > I thought we now also have had a discussion about the=20 > responses, and agreed that it from a pure protocol logic=20 > perspective would cause no harm. >=20 > >As I said before to Roland, if there is interest in doing=20 > this it should be addressed in a separate I-D giving the=20 > >background, requirements, mechanism, etc. >=20 > Of course it can be done that way. But, isn't the issue that=20 > we then may end up with two mechanisms of doing the same way=20 > - the "request way" described in the connected identity=20 > draft, and the "response way" to be described in another draft?=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 05 May 2006 08:39 > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > > Hi, > >=20 > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > mandatory reflection of the original To and From URI in mid-dialog=20 > > requests will be deprecated in a > > >subsequent revision of this specification." > >=20 > > Ok, I appologize for missing that. > >=20 > > However, that doesn't prevent us from also allowing to=20 > change the URI=20 > > in responses in a "subsequence revision". > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: "Christer Holmberg (JO/LMF)" > > To: "Elwell, John" ; "Jesske, R"=20 > > ; > > Cc: ; > > Sent: Friday, May 05, 2006 9:22 AM > > Subject: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi, > >=20 > > >Technically it might work, but RFC3261 neither gives > > permission to change > > >the To header field URI in a response nor hints at a future > > lifting of this > > >restriction. > >=20 > > So, where does RFC3261 give permisson to change the To header field=20 > > URI later in a request, then??? > >=20 > > I thought the changing of the URI was something that THIS GROUP has=20 > > agreed is to be allowed. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 04 May 2006 21:55 > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > Hi, > > > > > > From the safeness point of view, I thought we already > > agreed (at least > > > I haven't heard any disagreement) that doing it would not=20 > be unsafe,=20 > > > since the arguments that modifying the To and/or From > > header URI would > > > affect the transaction logic were not true. > > > > > > Regards, > > > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 4. toukokuuta 2006 13:39 > > > To: Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > Roland, > > > > > > Well, you would need to convince the community that this is a=20 > > > worthwhile and safe thing to do. Agreement to date is=20 > only to change=20 > > > From and To header field URIs in mid-dialog requests. > > > Changing the To header field URI in a response would > > require separate > > > agreement. I suggest you write an I-D and try to get > > backing. However, > > > I fear you will encounter strong opposition. > > > > > > Regards, > > > > > > John > > > > > > > -----Original Message----- > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > Sent: 04 May 2006 09:37 > > > > To: Elwell, John; sip@ietf.org > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > esasaki@NTT-AT.COM > > > > Subject: AW: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Dear John et all, > > > > I'm sorry to go again into the opposite oppinion but=20 > I'm still in=20 > > > > favour of enhancing the draft to provide identity in=20 > the To header=20 > > > > field URI of a response. > > > > > > > > I don't know if we have to rediscuss all the possibilities and=20 > > > > assumptions. But fact is that such a to header change would > > > be useful > > > > for some services. > > > > > > > > Best Regards > > > > > > > > Roland > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > An: sip@ietf.org > > > > > Betreff: [Sip] Issue 1 in > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > was raised > > > > > subsequently. This mail initiates discussion on the first > > > issue. I > > > > > will initiate discussion on the other three issues in=20 > separate=20 > > > > > mails. > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > this draft > > > > > intentionally does not address response identity, and > > > therefore the > > > > > identity of a dialog-forming responder to an INVITE=20 > request is=20 > > > > > conveyed in a separate request (e.g., UPDATE) in the reverse=20 > > > > > direction rather than in the response to the INVITE=20 > request. The=20 > > > > > open issue is stated as: > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > URI in the To > > > > > header field of a response to change compared with > > > > the To header > > > > > field in a request? This could convey a connected > > > > identity in a > > > > > response to an INVITE request, but it would not be=20 > > > > > authenticated. > > > > > Authentication would have to rely on transitive > > > trust, which > > > > > might > > > > > be feasible in a closed environment where the sips > > > > URI scheme is > > > > > used." > > > > > > > > > > There was considerable list discussion on this shortly after > > > > > IETF65 with no > > > > > resolution. I won't attempt to summarise it. My opinion > > > > (for what it's > > > > > worth) is as follows. > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From header=20 > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > these will > > > > > be allowed to change mid-dialog), it says nothing to=20 > warn of any=20 > > > > > future removal of the requirement that the To header > > field URI in > > > > > the response be the same as that in the request. > > > Therefore I believe > > > > > it would be dangerous to specify such a change to the=20 > To header=20 > > > > > field URI. > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > authenticated > > > > > identity, i.e., to complement the sip-identity draft. An > > > identity in > > > > > the To header field of a response cannot be=20 > authenticated, for=20 > > > > > reasons stated many times on this list and at meetings. > > > Therefore, > > > > > at least in the Internet, a response identity would=20 > have little=20 > > > > > value. > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > that path were > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > message to > > > > > this list on 5th April. > > > > > > > > > > 4. In closed environments an unauthenticated response > > > identity might > > > > > have some value. But this could be achieved using > > > > P-Asserted-Identity, say, > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft=20 > to provide=20 > > > > > identity in the To header field URI of a response. Can > > > people agree > > > > > to this resolution of the issue? > > > > > > > > > > John > > > > > > > > > > > -----Original Message----- > > > > > > From: Internet-Drafts@ietf.org > > [mailto:Internet-Drafts@ietf.org] > > > > > > Sent: 26 April 2006 20:50 > > > > > > To: i-d-announce@ietf.org > > > > > > Cc: sip@ietf.org > > > > > > Subject: [Sip] I-D > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts > > > > > > directories. > > > > > > This draft is a work item of the Session Initiation=20 > Protocol=20 > > > > > > Working Group of the IETF. > > > > > > > > > > > > Title : Connected Identity in the Session=20 > Initiation Protocol=20 > > > > > > (SIP) > > > > > > Author(s) : J. Elwell > > > > > > Filename : > > > draft-ietf-sip-connected-identity-00.txt > > > > > > Pages : 20 > > > > > > Date : 2006-4-26 > > > > > > > > > > > > Because of retargeting of a Session Initiation Protocol > > > > > > (SIP) dialog- > > > > > > forming request, the UAS can have a different identity > > > > > from that in > > > > > > the To header. This document provides a means for > > > that 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 PSTN > > > > > > behind a gateway. This document normatively updates RFC > > > > > > 3261 (SIP). > > > > > > This work is being discussed on the sip@ietf.org > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > dentity-00.txt > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > message to > > > > > > i-d-announce-request@ietf.org with the word=20 > unsubscribe in the=20 > > > > > > 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.=20 > > Login with > > > > > > the username "anonymous" and a password of your > > e-mail address. > > > > > > After > > > > logging in, > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > 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-00.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > document in=20 > > > > > > 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=20 > > > > > > "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=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=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 Tue May 09 14:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXLh-0001h1-8Q; Tue, 09 May 2006 14:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXLf-0001gv-Oo for sip@ietf.org; Tue, 09 May 2006 14:54:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXLe-0007Ow-DC for sip@ietf.org; Tue, 09 May 2006 14:54:19 -0400 Received: from [64.101.173.135] ([64.101.173.135]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k49ItEtA032256 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 9 May 2006 13:55:15 -0500 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Tue, 9 May 2006 13:54:08 -0500 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Sip] Mismatch in registry policy requirements of RFC 3969 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 3969 defines the registry for SIP/SIPS URI parameters. It currently says: 4.2. Registration Policy for SIP and SIPS URI Parameters As per the terminology in RFC 2434 [4], the registration policy for SIP and SIPS URI parameters shall be "Specification Required". For the purposes of this registry, the parameter for which IANA registration is requested MUST be defined by a standards-track RFC. Note that the above two paragraphs seem to be self contradictory. "Specification Required" means 3GPP and recognized bodies can define parameters by publishing specifications. But"Standards Track RFC" means only IETF can do so, and it has to be done with an IETF- consensus standards-track document. Note that the IANA registry currently says: SIP/SIPS URI Parameters RFC3969 Specification Required SIP/SIPS URI Parameters - per [RFC3969] (New registrations are via Specification Required) This means that the current IANA policy for this registry is "Specification Required". Which did we mean? Personally, I lean toward the current interpretation, "Specification required", but I think we need to get this clarified (assuming we haven't already and I just forgot it, which happens). -- 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 May 09 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 1FdXYm-0000B9-S4; Tue, 09 May 2006 15:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXYl-00008R-Jt for sip@ietf.org; Tue, 09 May 2006 15:07:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXYl-00081J-94 for sip@ietf.org; Tue, 09 May 2006 15:07:51 -0400 Received: from [64.101.173.135] ([64.101.173.135]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k49J8j13032314 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 May 2006 14:08:46 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Tue, 9 May 2006 14:07:39 -0500 To: SIP IETF X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule , "Kevin Lingle \(\(klingle\)\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 May 9, 2006, at 3:47 AM, Jean-Francois Mule wrote: > > If it is true that the 3rd party mechanism intended and defined by > 3261 is used by some implementations as we read in the thread, even > if the best current practices for allowing/disallowing 3rd party > reg have evolved, this object could be set by the registrar. > So does anybody out there have or envision a registrar that would distinguish third-party registrations from other registrations and track them differently? -- 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 May 09 15:11:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXaJ-000159-Cu; Tue, 09 May 2006 15:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXaH-000127-B2 for sip@ietf.org; Tue, 09 May 2006 15:09:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXaF-00083Q-VP for sip@ietf.org; Tue, 09 May 2006 15:09:25 -0400 Received: from [64.101.173.135] ([64.101.173.135]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k49JAMYP032332 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 May 2006 14:10:23 -0500 In-Reply-To: <32857.24.199.99.149.1147168071.squirrel@webmail.cs.columbia.edu> References: <445F3CF3.5000506@motorola.com> <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> <19BBD41F-0902-43D4-87FA-25D1AF95E83F@softarmor.com> <32857.24.199.99.149.1147168071.squirrel@webmail.cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37772229-4502-4C6B-BAE6-3C79E7997914@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Answer Mode Date: Tue, 9 May 2006 14:09:15 -0500 To: ac2491@cs.columbia.edu X-Mailer: Apple Mail (2.749.3) 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 Ah! I read "draft should suggest usage" to say that you thought the draft should be modified to suggest the usage. Instead, I now understand you to mean "If your read the draft, it will explain the usage well enough that you should get it." Is that right? -- Dean On May 9, 2006, at 4:47 AM, ac2491@cs.columbia.edu wrote: > Hi, > > Was just pointing out the usages given in the drarf ;-) > > -Anurag > >> >> On May 8, 2006, at 10:46 AM, ac2491@cs.columbia.edu wrote: >> >>> Hi Preeti, >>> >>> For my aplication I used Answer-mode as auto and appropriately >>> handled SIP >>> signalling (draft should suggest usage). If it was not auto >>> application >>> defaulted to manual (SIP signalling for manual ie human >>> intervention (pick >>> up phone) for call setup). >>> >> >> If you'd like to send some text suggesting usage, it can probably be >> incorporated. Personally I though the draft was already fairly clear >> here, but it must not be (given the questions), so let's fix it. >> >> -- >> Dean >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 09 15:25:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXnx-0006kk-QU; Tue, 09 May 2006 15:23:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXnv-0006iR-TB for sip@ietf.org; Tue, 09 May 2006 15:23:31 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXnt-0008Tm-HD for sip@ietf.org; Tue, 09 May 2006 15:23:31 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by test-iport-1.cisco.com with ESMTP; 09 May 2006 12:23:29 -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/8.12.11) with ESMTP id k49JNSjR011531; Tue, 9 May 2006 12:23:28 -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 k49JNRJl019371; Tue, 9 May 2006 12:23:28 -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.211); Tue, 9 May 2006 15:23:27 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 15:23:27 -0400 Message-ID: <4460EC2E.6060307@cisco.com> Date: Tue, 09 May 2006 15:23:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Dean Willis Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) References: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> In-Reply-To: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 19:23:27.0388 (UTC) FILETIME=[0C3B55C0:01C6739E] DKIM-Signature: a=rsa-sha1; q=dns; l=1445; t=1147202609; x=1148066609; c=relaxed/simple; s=sjdkim8001; 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=203rd=20party=20registration=20(was=20RE=3A=20[Sip]=20SIP=20MIB=20 ietf-sip-mib=09comments); X=v=3Dcisco.com=3B=20h=3DbkBK8XFfKJs2b7AS3PztOa1lyUU=3D; b=DvRiu1R5qq7h5+iDyoUpPnPeLJnIvPjlqmX+SBI+Wyvdr4EJKb+fb2G0z0KGjn6RPhXThYvo 3MSvKTscdLU6X7cQt9+IyWwg9JYQHO5FRppufLp8rzhG2btx/hbCPGVH; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP IETF , "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule , "Kevin Lingle \(\(klingle\)\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 missed all the earlier parts of this thread. (Because I have a rule that I always delete any mail that contains "mib" in its subject.) So I don't understand the context for this. But... Dean Willis wrote: > > On May 9, 2006, at 3:47 AM, Jean-Francois Mule wrote: > >> >> If it is true that the 3rd party mechanism intended and defined by >> 3261 is used by some implementations as we read in the thread, even if >> the best current practices for allowing/disallowing 3rd party reg have >> evolved, this object could be set by the registrar. >> > > So does anybody out there have or envision a registrar that would > distinguish third-party registrations from other registrations and track > them differently? Well, there are some clear examples of that. In particular, IMS doesn't support 3rd party registrations from real users. And it uses a bastardized version of 3rd party registration between the S-CSCF and Application Servers. These are entirely different. And I *think* -outbound- deprecates 3rd party registrations, doesn't it? IMO 3rd party registration is a very reasonable, and potentially useful, capability. It makes perfect sense if you have reasonable (and distinct) authentication and authorization capabilities. I have heard of at least one implementation that supports 3rd party registration. But making it work for IMS is probably out of the question. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 09 16:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYn9-0002dK-Pc; Tue, 09 May 2006 16:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYn9-0002dF-3B for sip@ietf.org; Tue, 09 May 2006 16:26:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYn7-00045q-Qo for sip@ietf.org; Tue, 09 May 2006 16:26:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 May 2006 13:26:45 -0700 X-IronPort-AV: i="4.05,107,1146466800"; d="scan'208"; a="274111925:sNHT74779690" 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/8.12.11) with ESMTP id k49KQjLE009627; Tue, 9 May 2006 13:26:45 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k49KQjJj016341; Tue, 9 May 2006 13:26:45 -0700 (PDT) Received: from [192.168.1.2] ([10.21.114.175]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 13:26:44 -0700 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF08C5EBE1@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF08C5EBE1@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A71FBA9-C58A-4C49-B7DD-44D8D7132651@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 9 May 2006 13:26:48 -0700 To: Francois Audet X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 09 May 2006 20:26:44.0966 (UTC) FILETIME=[E3C3C060:01C673A6] DKIM-Signature: a=rsa-sha1; q=dns; l=672; t=1147206405; x=1148070405; c=relaxed/simple; s=sjdkim5001; 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=20draft-audet-sip-sips-guidelines-00.txt=3A=20use=20of=20transport =3Dtls; X=v=3Dcisco.com=3B=20h=3DbJpD2jbhzn/yQHlwX2zpavgZhBI=3D; b=KKCYHTPK+XG8yEP9KByUwhna4todJCwbunP+AJFu5TW6rz7H96aUm6d/OTXk5knzWv1cj2Cn IvmtJrEknpmAUHATf/BVxXArL/GTsP+SXnCLSHNFkTvWJjg648/KUOWj; 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: 7d33c50f3756db14428398e2bdedd581 Cc: SIP IETF , Paul Kyzivat Subject: [Sip] Re: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Apr 17, 2006, at 2:33 PM, Francois Audet wrote: > >>> You would send the REGISTER using TLS in this case, but you >> would be >>> prepared to receive incoming requests on this connection >> using either >>> TLS or TCP. >> >> So when using sip, the messages over the connection would not be >> encrypted, but when using sips they would? >> >> Can you do that with TLS? I'm no expert, but I thought once you >> establish a connection, it starts out TCP but if you do the TLS >> handshake then it is all TLS from then on. > > I'm not sure either. Cullen? Yes - correct - however, you could still open new TCP or TLS connections on the same port. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 09 17:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZSv-0007Ve-5u; Tue, 09 May 2006 17:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZSt-0007VZ-9U for sip@ietf.org; Tue, 09 May 2006 17:09:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZSs-0006VK-1g for sip@ietf.org; Tue, 09 May 2006 17:09:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2006 14:09:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,107,1146466800"; d="scan'208"; a="27685757:sNHT23285236" 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 k49L9pTL007115; Tue, 9 May 2006 17:09:51 -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.211); Tue, 9 May 2006 17:09:50 -0400 Received: from [161.44.79.144] ([161.44.79.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 17:09:50 -0400 Message-ID: <4461051C.1080206@cisco.com> Date: Tue, 09 May 2006 17:09:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Cullen Jennings References: <1ECE0EB50388174790F9694F77522CCF08C5EBE1@zrc2hxm0.corp.nortel.com> <2A71FBA9-C58A-4C49-B7DD-44D8D7132651@cisco.com> In-Reply-To: <2A71FBA9-C58A-4C49-B7DD-44D8D7132651@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 21:09:50.0538 (UTC) FILETIME=[E8E2BAA0:01C673AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: SIP IETF , Francois Audet Subject: [Sip] Re: draft-audet-sip-sips-guidelines-00.txt: use of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 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, I have lost the context for this discussion. But I find it difficult to see how opening another connection would help. At least in the case of -outbound-, the new connection would have to be in the direction from the UA inward. And then before it could be used there would have to be a REGISTER over it. I don't know what the reg-id would have to be in that case for it to be useful. Paul Cullen Jennings wrote: > > On Apr 17, 2006, at 2:33 PM, Francois Audet wrote: > >> >>>> You would send the REGISTER using TLS in this case, but you >>> would be >>>> prepared to receive incoming requests on this connection >>> using either >>>> TLS or TCP. >>> >>> So when using sip, the messages over the connection would not be >>> encrypted, but when using sips they would? >>> >>> Can you do that with TLS? I'm no expert, but I thought once you >>> establish a connection, it starts out TCP but if you do the TLS >>> handshake then it is all TLS from then on. >> >> I'm not sure either. Cullen? > > Yes - correct - however, you could still open new TCP or TLS connections > on the same port. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 09 18:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaNp-0005tv-1z; Tue, 09 May 2006 18:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdaNn-0005tX-V4 for sip@ietf.org; Tue, 09 May 2006 18:08:43 -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 1FdZ7a-0005RY-OD for sip@ietf.org; Tue, 09 May 2006 16:47:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdYvz-0003m7-M7 for sip@ietf.org; Tue, 09 May 2006 16:35:58 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2006 13:35:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,107,1146466800"; d="scan'208"; a="27681941:sNHT21909592" 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 k49KZtTL028869; Tue, 9 May 2006 16:35:55 -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.211); Tue, 9 May 2006 16:35:55 -0400 Received: from [161.44.55.197] ([161.44.55.197]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 16:35:54 -0400 Message-ID: <4460FD29.1070101@cisco.com> Date: Tue, 09 May 2006 16:35:53 -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] ISSUE 2 in Hitchhikers guide to SIP: What constitutes C ore SIP References: <50B1CBA96870A34799A506B2313F266708DDAB43@ntht201e.siemenscomms.co.uk> In-Reply-To: <50B1CBA96870A34799A506B2313F266708DDAB43@ntht201e.siemenscomms.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2006 20:35:54.0697 (UTC) FILETIME=[2B6E0B90:01C673A8] X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 - this was the justification for RFC3265 itself. -Jonathan R. Elwell, John wrote: > Jonathan, > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: 08 May 2006 20:04 >>To: IETF SIP List >>Subject: [Sip] ISSUE 2 in Hitchhikers guide to SIP: What >>constitutes Core SIP >> >>One of the categorizations I used for the hitchikers guide were "Core" >>SIP specifications. THe document says that: >> >> >>>The core SIP specifications represent essential functionality for >>>almost any implementation. >> >>this is somewhat vague. I have in mind a more concrete >>definition that I >>think makes more sense. I'd propose: >> >> >>>The core SIP specifications represent the set of >> >>specifications whose >> >>>functionality is broadly applicable. An extension is broadly >>>applicable if it fits into one of the following categories: >>> >>>* For specifications that impact SIP session management, the >>>extension would be used for almost every session initiated by a user >>>agent >>> >>>* For specifications that impact SIP registrations, the extension >>>would be used for almost every registration initiated by a >> >>user agent >> >>>* For specifications that impact SIP subscriptions, the extension >>>would be used for almost every subscription initiated by a >> >>user agent > > [JRE] I didn't notice anything that fell into this category and I have a > hard time thinking of something that might (unless you use this to justify > including RFC3265). > > John > -- 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 May 09 18:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdb2I-0006xf-T9; Tue, 09 May 2006 18:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdb2I-0006xV-0b for sip@ietf.org; Tue, 09 May 2006 18:50:34 -0400 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdb2H-0002Mv-It for sip@ietf.org; Tue, 09 May 2006 18:50:33 -0400 Received: by nz-out-0102.google.com with SMTP id i28so1621056nzi for ; Tue, 09 May 2006 15:50:33 -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=mbNEqg1tT1Ov+FF/PclTE5zXEaXnW2nOGadCCAE+eqiI0PcSrIs3KBl4u1ItsfOTuDw05Zk6m3ifHpci1SvXDij7rg6RJCSanvWSucJVx2k1LhzgV9XybFrImEAAYOm5WxpXA768FJOmZQF8j2HY5myiH1QzkRNn5qo0QwUVygw= Received: by 10.36.252.65 with SMTP id z65mr5720229nzh; Tue, 09 May 2006 15:50:33 -0700 (PDT) Received: by 10.36.126.10 with HTTP; Tue, 9 May 2006 15:50:33 -0700 (PDT) Message-ID: <4ff4e7370605091550j53c3d819v9e8b9c54b7276540@mail.gmail.com> Date: Tue, 9 May 2006 15:50:33 -0700 From: Venkatesh To: "Paul Kyzivat" Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) In-Reply-To: <4460EC2E.6060307@cisco.com> MIME-Version: 1.0 References: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> <4460EC2E.6060307@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Juergen Schoenwaelder , SIP IETF , "Kevin Lingle \(\(klingle\)\)" , "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule , 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: , Content-Type: multipart/mixed; boundary="===============2029131875==" Errors-To: sip-bounces@ietf.org --===============2029131875== Content-Type: multipart/alternative; boundary="----=_Part_2829_21125225.1147215033041" ------=_Part_2829_21125225.1147215033041 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think there was a discussion at length in the mailing list that talked about outbound deprecating third party registrations and concluded that it outbound allows third party registrations where From!=3DTo. http://www1.ietf.org/mail-archive/web/sip/current/msg13968.html Like you mention, third party registrations are useful. It is currently use= d in the current bridged line appearance draft (draft-anil-sipping-bla-02) an= d there are a few implementations that support the same. Venkatesh On 5/9/06, Paul Kyzivat wrote: > > I have missed all the earlier parts of this thread. (Because I have a > rule that I always delete any mail that contains "mib" in its subject.) > > So I don't understand the context for this. But... > > Dean Willis wrote: > > > > On May 9, 2006, at 3:47 AM, Jean-Francois Mule wrote: > > > >> > >> If it is true that the 3rd party mechanism intended and defined by > >> 3261 is used by some implementations as we read in the thread, even if > >> the best current practices for allowing/disallowing 3rd party reg have > >> evolved, this object could be set by the registrar. > >> > > > > So does anybody out there have or envision a registrar that would > > distinguish third-party registrations from other registrations and trac= k > > them differently? > > Well, there are some clear examples of that. In particular, IMS doesn't > support 3rd party registrations from real users. And it uses a > bastardized version of 3rd party registration between the S-CSCF and > Application Servers. These are entirely different. > > And I *think* -outbound- deprecates 3rd party registrations, doesn't it? > > IMO 3rd party registration is a very reasonable, and potentially useful, > capability. It makes perfect sense if you have reasonable (and distinct) > authentication and authorization capabilities. > > I have heard of at least one implementation that supports 3rd party > registration. > > But making it work for IMS is probably out of the question. > > 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 > ------=_Part_2829_21125225.1147215033041 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I think there was a discussion at length in the mailing list that talk= ed about outbound deprecating third party registrations and concluded that = it outbound allows third party registrations where From!=3DTo.
 
 
Like you mention, third party registrations are useful. It is currentl= y used in the current bridged line appearance draft (draft-anil-sipping-bla= -02) and there are a few implementations that support the same.
&nb= sp;
Venkatesh
 
On 5/9/06, P= aul Kyzivat <pkyzivat@cisco.co= m> wrote:
I have missed all the earlier pa= rts of this thread. (Because I have a
rule that I always delete any mail= that contains "mib" in its subject.)

So I don't understand the context for this. But...

Dean Will= is wrote:
>
> On May 9, 2006, at 3:47 AM, Jean-Francois Mule wr= ote:
>
>>
>> If it is true that the 3rd party mecha= nism intended and defined by
>> 3261 is used by some implementations as we read in the thread,= even if
>> the best current practices for allowing/disallowing 3r= d party reg have
>> evolved, this object could be set by the regis= trar.
>>
>
> So does anybody out there have or envision a r= egistrar that would
> distinguish third-party registrations from othe= r registrations and track
> them differently?

Well, there are = some clear examples of that. In particular, IMS doesn't
support 3rd party registrations from real users. And it uses a
basta= rdized version of 3rd party registration between the S-CSCF and
Applicat= ion Servers. These are entirely different.

And I *think* -outbound- = deprecates 3rd party registrations, doesn't it?

IMO 3rd party registration is a very reasonable, and potentially us= eful,
capability. It makes perfect sense if you have reasonable (and dis= tinct)
authentication and authorization capabilities.

I have hear= d of at least one implementation that supports 3rd party
registration.

But making it work for IMS is probably out of the = question.

       Paul

_________= ______________________________________
Sip mailing list   https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW deve= lopment of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on curr= ent sip
Use sipping@ietf.org for new de= velopments on the application of sip

------=_Part_2829_21125225.1147215033041-- --===============2029131875== 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 --===============2029131875==-- From sip-bounces@ietf.org Tue May 09 21:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdd64-0004hp-G7; Tue, 09 May 2006 21:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdd63-0004hk-2j for sip@ietf.org; Tue, 09 May 2006 21:02:35 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdd60-0007mZ-Rd for sip@ietf.org; Tue, 09 May 2006 21:02:35 -0400 Received: from hydra.cs.columbia.edu (IDENT:y8iGM8gJ42Dz1OVtTp7nHB8xB/32XEDe@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4A12KX6007459 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 9 May 2006 21:02:30 -0400 (EDT) Received: from webmail.cs.columbia.edu (IDENT:lVa15vyKJN0m88ArzBGtJHnAXL9PfStB@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id k4A12KIL010089; Tue, 9 May 2006 21:02:20 -0400 Received: from 128.59.23.101 (SquirrelMail authenticated user ac2491) by webmail.cs.columbia.edu with HTTP; Tue, 9 May 2006 21:02:20 -0400 (EDT) Message-ID: <2271.128.59.23.101.1147222940.squirrel@webmail.cs.columbia.edu> In-Reply-To: <37772229-4502-4C6B-BAE6-3C79E7997914@softarmor.com> References: <445F3CF3.5000506@motorola.com> <32819.24.199.99.149.1147103215.squirrel@webmail.cs.columbia.edu> <19BBD41F-0902-43D4-87FA-25D1AF95E83F@softarmor.com> <32857.24.199.99.149.1147168071.squirrel@webmail.cs.columbia.edu> <37772229-4502-4C6B-BAE6-3C79E7997914@softarmor.com> Date: Tue, 9 May 2006 21:02:20 -0400 (EDT) Subject: Re: [Sip] Answer Mode From: ac2491@cs.columbia.edu To: "Dean Willis" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.7 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, Yes that is what I meant. I apologize for the confusion, will state more unambiguously in the next posts. Thanks -Anurag > > > Ah! I read "draft should suggest usage" to say that you thought the > draft should be modified to suggest the usage. > > Instead, I now understand you to mean "If your read the draft, it > will explain the usage well enough that you should get it." > > Is that right? > > -- > Dean > > On May 9, 2006, at 4:47 AM, ac2491@cs.columbia.edu wrote: > >> Hi, >> >> Was just pointing out the usages given in the drarf ;-) >> >> -Anurag >> >>> >>> On May 8, 2006, at 10:46 AM, ac2491@cs.columbia.edu wrote: >>> >>>> Hi Preeti, >>>> >>>> For my aplication I used Answer-mode as auto and appropriately >>>> handled SIP >>>> signalling (draft should suggest usage). If it was not auto >>>> application >>>> defaulted to manual (SIP signalling for manual ie human >>>> intervention (pick >>>> up phone) for call setup). >>>> >>> >>> If you'd like to send some text suggesting usage, it can probably be >>> incorporated. Personally I though the draft was already fairly clear >>> here, but it must not be (given the questions), so let's fix it. >>> >>> -- >>> Dean >>> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 10 05:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkXK-0000zW-Ar; Wed, 10 May 2006 04:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkXI-0000zR-Un for sip@ietf.org; Wed, 10 May 2006 04:59:12 -0400 Received: from bzq-114-71-192.cust.bezeqint.net ([192.114.71.192] helo=calllan.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdkXH-0002Xo-KV for sip@ietf.org; Wed, 10 May 2006 04:59:12 -0400 Received: from yonicomp ([192.168.0.13]) by calllan.com (calllan.com [192.114.71.192]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 27-md50000000001.tmp for ; Wed, 10 May 2006 12:03:08 +0200 From: "Yonatan Doron" To: "'Franz Edler'" Subject: RE: [Sip] SIP Call Hold reply Date: Wed, 10 May 2006 11:57:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZv1Yzx9sJMosW9SgypDJYCEdWE1wB542yAABGi+WAAH2k9oAABBT3wAGSEENA= In-Reply-To: <000d01c6727e$223f0900$0600a8c0@notebook> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Processed: calllan.com, Wed, 10 May 2006 12:03:08 +0200 (not processed: spam filter disabled) X-MDRemoteIP: 192.168.0.13 X-Return-Path: yoni@usbphone.com X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: One more thing that isn't quite clear to me: When my client requests to put a stream on hold, should it stop sending the media at the time when it sends the request, or should it first wait for a reply saying the hold-request was accepted, and only then stop sending ? -----Original Message----- From: Franz Edler [mailto:franz.edler@ycn.com] Sent: Monday, May 08, 2006 11:02 AM To: 'Yonatan Doron' Cc: sip@ietf.org Subject: AW: [Sip] SIP Call Hold reply > Actually, I am currently working with a bit old version of eyeBeam > (version 3013), and the latest version of Express Talk. Both answer a > hold request according to the old RFC. > Can you recommend of any good free SIP clients out there which comply > to the latest RFC ? Actually I wonder that your eyeBeam does not follow RFC3264. I just tried my eyeBeam (Version 1.5.4) and found hold mechanism correctly implemented (I can send you the trace-file). Also the hardphones I use (snom and Thomson) have it correctly implemented. I don't use free clients since I have eyeBeam. regards Franz BTW: This seems to become more a question for the "sip-implementers" mailing-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 Wed May 10 05:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdlHS-0002lo-H2; Wed, 10 May 2006 05:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdlHQ-0002lj-M0 for sip@ietf.org; Wed, 10 May 2006 05:46:52 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdlHQ-0004T1-DS for sip@ietf.org; Wed, 10 May 2006 05:46:52 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4A9khoS029438; Wed, 10 May 2006 04:46:43 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 10 May 2006 10:46:42 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012D52958@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Paul Kyzivat , Dean Willis Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib co mments) Date: Wed, 10 May 2006 10:46:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: SIP IETF , "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule , "Kevin Lingle \(\(klingle\)\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org And in any case, at the current time, IMS OA&M doesn't appear to use the MIB. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 09 May 2006 20:23 > To: Dean Willis > Cc: SIP IETF; Romascanu, Dan ((Dan)); Jean-Francois Mule; Kevin Lingle > ((klingle)); Juergen Schoenwaelder > Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB > ietf-sip-mib > comments) > > > I have missed all the earlier parts of this thread. (Because I have a > rule that I always delete any mail that contains "mib" in its > subject.) > > So I don't understand the context for this. But... > > Dean Willis wrote: > > > > On May 9, 2006, at 3:47 AM, Jean-Francois Mule wrote: > > > >> > >> If it is true that the 3rd party mechanism intended and defined by > >> 3261 is used by some implementations as we read in the > thread, even if > >> the best current practices for allowing/disallowing 3rd > party reg have > >> evolved, this object could be set by the registrar. > >> > > > > So does anybody out there have or envision a registrar that would > > distinguish third-party registrations from other > registrations and track > > them differently? > > Well, there are some clear examples of that. In particular, > IMS doesn't > support 3rd party registrations from real users. And it uses a > bastardized version of 3rd party registration between the S-CSCF and > Application Servers. These are entirely different. > > And I *think* -outbound- deprecates 3rd party registrations, > doesn't it? > > IMO 3rd party registration is a very reasonable, and > potentially useful, > capability. It makes perfect sense if you have reasonable > (and distinct) > authentication and authorization capabilities. > > I have heard of at least one implementation that supports 3rd party > registration. > > But making it work for IMS is probably out of the question. > > Paul > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 10 11:21:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqTO-0002wz-1p; Wed, 10 May 2006 11:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqTN-0002wT-4z for sip@ietf.org; Wed, 10 May 2006 11:19:33 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqTJ-00027Y-PP for sip@ietf.org; Wed, 10 May 2006 11:19:33 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4AFKRZH003612 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 10 May 2006 10:20:29 -0500 In-Reply-To: <4460EC2E.6060307@cisco.com> References: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> <4460EC2E.6060307@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05CD3DD2-EA4B-4055-AF43-7B944342FA35@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Wed, 10 May 2006 10:19:22 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP IETF , "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule , "Kevin Lingle \(\(klingle\)\)" , Juergen Schoenwaelder X-BeenThere: sip@ietf.org X-Mailman-Version: 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 May 9, 2006, at 2:23 PM, Paul Kyzivat wrote: > > I have heard of at least one implementation that supports 3rd party > registration. But do we have any need to track and report on 3rd party registrations at the MIB level differently than we do 1st party registrations? Or is a registration just a registration from a peg-count perspective? -- 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 May 10 12:40:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdrhe-0005I4-9u; Wed, 10 May 2006 12:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdrhc-0005Hz-UG for sip@ietf.org; Wed, 10 May 2006 12:38: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 1Fdrhc-0005eo-23 for sip@ietf.org; Wed, 10 May 2006 12:38:20 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IZ200M0166QPC@siemenscomms.co.uk> for sip@ietf.org; Wed, 10 May 2006 17:37:43 +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 <0IZ200K855Y09X@siemenscomms.co.uk>; Wed, 10 May 2006 17:32:24 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 10 May 2006 17:31:55 +0100 Content-return: allowed Date: Wed, 10 May 2006 17:31:54 +0100 From: "Elwell, John" Subject: RE: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt To: "Dolly, Martin C, ALABS" , "Jesske, R" , christer.holmberg@ericsson.com, jbemmel@zonnet.nl, sip@ietf.org Message-id: <50B1CBA96870A34799A506B2313F266708E22F34@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: esasaki@NTT-AT.COM, chister.holmberg@ericsson.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 Martin, Noted, but why can't P-Asserted-Identity be used for your purposes? If = some new mechanism is required, why does it need to be tied to the present connected-identity draft, which focuses on a cryptographically = authenticated identity? John=20 > -----Original Message----- > From: Dolly, Martin C, ALABS [mailto:mdolly@att.com]=20 > Sent: 09 May 2006 18:37 > To: Jesske, R; christer.holmberg@ericsson.com; Elwell, John;=20 > jbemmel@zonnet.nl; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: RE: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 > Hello, >=20 > We have a similar need in ATIS. I support what Roland/TISPAN=20 > is proposing. >=20 > Cheers, >=20 > Martin=20 >=20 > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: Monday, May 08, 2006 6:53 AM > To: christer.holmberg@ericsson.com; john.elwell@siemens.com;=20 > jbemmel@zonnet.nl; sip@ietf.org > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > Subject: AW: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 > Hi, > As Christer said, I don't know if this is a straight way=20 > forward to wait for an further document describing the other=20 > way around. > We (seen from TISPAN purpose) have a requirement of an=20 > additional connected identity in the response and that can be=20 > fulfilled by changing the to header in the response.=20 > The discussion showed it that there is no harm in changing=20 > the to header field in a response. > Why don't do it? >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com]=20 > > Gesendet: Montag, 8. Mai 2006 11:12 > > An: Elwell, John; Jeroen van Bemmel; Jesske, Roland; sip@ietf.org > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > Betreff: RE: [Sip] Issue 1 in=20 > draft-ietf-sip-connected-identity-00.txt > >=20 > >=20 > >=20 > > Hi,=20 > >=20 > > >You are correct that it does not necessarily prevent us=20 > > changing the URI in a response in a "subsequent revision", but=20 > > >that is a different discussion from the discussion we have=20 > > already had and concluded on mid-dialog requests. > >=20 > > I thought we now also have had a discussion about the=20 > > responses, and agreed that it from a pure protocol logic=20 > > perspective would cause no harm. > >=20 > > >As I said before to Roland, if there is interest in doing=20 > > this it should be addressed in a separate I-D giving the=20 > > >background, requirements, mechanism, etc. > >=20 > > Of course it can be done that way. But, isn't the issue that=20 > > we then may end up with two mechanisms of doing the same way=20 > > - the "request way" described in the connected identity=20 > > draft, and the "response way" to be described in another draft?=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 05 May 2006 08:39 > > > To: Jeroen van Bemmel; Elwell, John; Jesske, R; sip@ietf.org > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > Subject: RE: [Sip] Issue 1 in=20 > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >RFC3261 Section 12.2.1.1: "[...] It is expected that > > > mandatory reflection of the original To and From URI in=20 > mid-dialog=20 > > > requests will be deprecated in a > > > >subsequent revision of this specification." > > >=20 > > > Ok, I appologize for missing that. > > >=20 > > > However, that doesn't prevent us from also allowing to=20 > > change the URI=20 > > > in responses in a "subsequence revision". > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > ----- Original Message ----- > > > From: "Christer Holmberg (JO/LMF)"=20 > > > > To: "Elwell, John" ; "Jesske, R"=20 > > > ; > > > Cc: ; > > > Sent: Friday, May 05, 2006 9:22 AM > > > Subject: RE: [Sip] Issue 1 in=20 > > draft-ietf-sip-connected-identity-00.txt > > >=20 > > >=20 > > >=20 > > > Hi, > > >=20 > > > >Technically it might work, but RFC3261 neither gives > > > permission to change > > > >the To header field URI in a response nor hints at a future > > > lifting of this > > > >restriction. > > >=20 > > > So, where does RFC3261 give permisson to change the To=20 > header field=20 > > > URI later in a request, then??? > > >=20 > > > I thought the changing of the URI was something that THIS=20 > GROUP has=20 > > > agreed is to be allowed. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: 04 May 2006 21:55 > > > > To: Elwell, John; Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > Hi, > > > > > > > > From the safeness point of view, I thought we already > > > agreed (at least > > > > I haven't heard any disagreement) that doing it would not=20 > > be unsafe,=20 > > > > since the arguments that modifying the To and/or From > > > header URI would > > > > affect the transaction logic were not true. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 4. toukokuuta 2006 13:39 > > > > To: Jesske, R; sip@ietf.org > > > > Cc: esasaki@NTT-AT.COM; chister.holmberg@ericsson.com > > > > Subject: RE: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > Roland, > > > > > > > > Well, you would need to convince the community that this is a=20 > > > > worthwhile and safe thing to do. Agreement to date is=20 > > only to change=20 > > > > From and To header field URIs in mid-dialog requests. > > > > Changing the To header field URI in a response would > > > require separate > > > > agreement. I suggest you write an I-D and try to get > > > backing. However, > > > > I fear you will encounter strong opposition. > > > > > > > > Regards, > > > > > > > > John > > > > > > > > > -----Original Message----- > > > > > From: Jesske, R [mailto:R.Jesske@t-com.net] > > > > > Sent: 04 May 2006 09:37 > > > > > To: Elwell, John; sip@ietf.org > > > > > Cc: chister.holmberg@ericsson.com;=20 > > > > > sebastien.garcin@francetelecom.com; Alexeitsev, D; > > > > esasaki@NTT-AT.COM > > > > > Subject: AW: [Sip] Issue 1 in > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > Dear John et all, > > > > > I'm sorry to go again into the opposite oppinion but=20 > > I'm still in=20 > > > > > favour of enhancing the draft to provide identity in=20 > > the To header=20 > > > > > field URI of a response. > > > > > > > > > > I don't know if we have to rediscuss all the=20 > possibilities and=20 > > > > > assumptions. But fact is that such a to header change would > > > > be useful > > > > > for some services. > > > > > > > > > > Best Regards > > > > > > > > > > Roland > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Gesendet: Dienstag, 2. Mai 2006 22:20 > > > > > > An: sip@ietf.org > > > > > > Betreff: [Sip] Issue 1 in > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > > > > > There are three open issues in this draft and a fourth that > > > > > was raised > > > > > > subsequently. This mail initiates discussion on the first > > > > issue. I > > > > > > will initiate discussion on the other three issues in=20 > > separate=20 > > > > > > mails. > > > > > > > > > > > > Issue 1 appears in section 5 and concerns the fact that > > > > this draft > > > > > > intentionally does not address response identity, and > > > > therefore the > > > > > > identity of a dialog-forming responder to an INVITE=20 > > request is=20 > > > > > > conveyed in a separate request (e.g., UPDATE) in=20 > the reverse=20 > > > > > > direction rather than in the response to the INVITE=20 > > request. The=20 > > > > > > open issue is stated as: > > > > > > > > > > > > "OPEN ISSUE. Should this be extended to allow a > > > > URI in the To > > > > > > header field of a response to change compared with > > > > > the To header > > > > > > field in a request? This could convey a connected > > > > > identity in a > > > > > > response to an INVITE request, but it would not be=20 > > > > > > authenticated. > > > > > > Authentication would have to rely on transitive > > > > trust, which > > > > > > might > > > > > > be feasible in a closed environment where the sips > > > > > URI scheme is > > > > > > used." > > > > > > > > > > > > There was considerable list discussion on this shortly = after > > > > > > IETF65 with no > > > > > > resolution. I won't attempt to summarise it. My opinion > > > > > (for what it's > > > > > > worth) is as follows. > > > > > > > > > > > > 1. Whereas RFC 3261 anticipates deprecating fixed=20 > > To/From header=20 > > > > > > field URIs throughout a dialog (i.e., it anticipates that > > > > these will > > > > > > be allowed to change mid-dialog), it says nothing to=20 > > warn of any=20 > > > > > > future removal of the requirement that the To header > > > field URI in > > > > > > the response be the same as that in the request. > > > > Therefore I believe > > > > > > it would be dangerous to specify such a change to the=20 > > To header=20 > > > > > > field URI. > > > > > > > > > > > > 2. The prime motivation for this draft was to provide > > > > authenticated > > > > > > identity, i.e., to complement the sip-identity draft. An > > > > identity in > > > > > > the To header field of a response cannot be=20 > > authenticated, for=20 > > > > > > reasons stated many times on this list and at meetings. > > > > Therefore, > > > > > > at least in the Internet, a response identity would=20 > > have little=20 > > > > > > value. > > > > > > > > > > > > 3. A comprehensive list of reasons for not going down > > > > that path were > > > > > > given by Jon Peterson (editor of the Identity draft) in a > > > > message to > > > > > > this list on 5th April. > > > > > > > > > > > > 4. In closed environments an unauthenticated response > > > > identity might > > > > > > have some value. But this could be achieved using > > > > > P-Asserted-Identity, say, > > > > > > rather than bending the rules for To headers in responses. > > > > > > > > > > > > Therefore I am NOT in favour of enhancing the draft=20 > > to provide=20 > > > > > > identity in the To header field URI of a response. Can > > > > people agree > > > > > > to this resolution of the issue? > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Internet-Drafts@ietf.org > > > [mailto:Internet-Drafts@ietf.org] > > > > > > > Sent: 26 April 2006 20:50 > > > > > > > To: i-d-announce@ietf.org > > > > > > > Cc: sip@ietf.org > > > > > > > Subject: [Sip] I-D > > > > ACTION:draft-ietf-sip-connected-identity-00.txt > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line > > > > Internet-Drafts > > > > > > > directories. > > > > > > > This draft is a work item of the Session Initiation=20 > > Protocol=20 > > > > > > > Working Group of the IETF. > > > > > > > > > > > > > > Title : Connected Identity in the Session=20 > > Initiation Protocol=20 > > > > > > > (SIP) > > > > > > > Author(s) : J. Elwell > > > > > > > Filename : > > > > draft-ietf-sip-connected-identity-00.txt > > > > > > > Pages : 20 > > > > > > > Date : 2006-4-26 > > > > > > > > > > > > > > Because of retargeting of a Session Initiation = Protocol > > > > > > > (SIP) dialog- > > > > > > > forming request, the UAS can have a different identity > > > > > > from that in > > > > > > > the To header. This document provides a means for > > > > that 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 PSTN > > > > > > > behind a gateway. This document normatively=20 > updates RFC > > > > > > > 3261 (SIP). > > > > > > > This work is being discussed on the sip@ietf.org > > > > mailing list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connected-i > > > > > > > dentity-00.txt > > > > > > > > > > > > > > To remove yourself from the I-D Announcement list, send a > > > > > > message to > > > > > > > i-d-announce-request@ietf.org with the word=20 > > unsubscribe in the=20 > > > > > > > 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.=20 > > > Login with > > > > > > > the username "anonymous" and a password of your > > > e-mail address. > > > > > > > After > > > > > logging in, > > > > > > > type "cd internet-drafts" and then "get=20 > > > > > > > draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > > > Send a message to: > > > > > > > mailserv@ietf.org. > > > > > > > In the body type: > > > > > > > "FILE > > > > > > >=20 > /internet-drafts/draft-ietf-sip-connected-identity-00.txt". > > > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the=20 > > document in=20 > > > > > > > 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=20 > > > > > > > "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=20 > 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 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 = > > > 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 >=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 May 10 12:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdrl2-0005WQ-9z; Wed, 10 May 2006 12:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdrl1-0005WL-6x for sip@ietf.org; Wed, 10 May 2006 12:41:51 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdrkz-0005t3-Qo for sip@ietf.org; Wed, 10 May 2006 12:41:51 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4AGfksV015301; Wed, 10 May 2006 11:41:46 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k4AGfkI20945; Wed, 10 May 2006 11:41:46 -0500 (CDT) Message-ID: <446217CA.6050109@lucent.com> Date: Wed, 10 May 2006 11:41:46 -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: "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: IETF SIP List Subject: [Sip] Initial review of sip-saml 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="===============0815647774==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0815647774== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010607080101050209060804" This is a cryptographically signed message in MIME format. --------------ms010607080101050209060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes: Here are initial comments based on the review of sip-saml I-D (-05). Thanks for getting this out. I hope these are helpful. I have divided them into a nits section (further down below) and a substantive comments section, which follows next. 1) In Section 1 itself, you may want to give a reference for "authorization certificates". I presume you meant rfc3281? Also, a reference for SPKI may help. I presume you meant rfc2692 and rfc2693. However, these are experimental RFCs, and I am curious whether there are any deployments. These do make for interesting reading, though (especially rfc2693). 2) I would actually put the current Section 3 *after* the current Section 4. The reason is that in Section 4, you define the terms (SAML profile, SAML binding, etc.) that are used liberally in Section 3. Thus, if you put Section 4 first, your reader will have a better idea of what you are talking about. 3) I believe that the first paragraph in Section 5 is very important since it provides guidance on why this specification is needed at all. Maybe some terse editing to further highlight this will help. Something along the lines of: Current use of SAML is strongly tied to its use with HTTP- based web browing. This is a natural outcome of its evolution. However, the next step in this evolution is using SAML in other contexts and protocols, such as Internet session signaling and SIP. While SIP is closely related to HTTP, it is distinct enough that a new SAML profile or profiles will need to be specified. Fortunately, this should not cause a problem since both SAML and SIP are designed to be extensible protocols. 4) Section 6.1. So, when I read the description, I am left to wonder what are Alice's "profile attributes" that the PSTN/SIP gateway provider imparts to Bob. Could you give some examples? Otherwise, all that I can think of is Alice's identity, which can be imparted to Bob. And doing so will not require SAML. 5) In Section 6.3, it is stated that "The Offer contains information about the three parties...". As far as I can see, the offer contains information about two parties: the merchant (Bob) and the user (Alice). The third party -- Payment Provider -- is brought into the equation with the Receipt (in step 4). 6) In section 9, there is an example of a signed SAML assertion. What is it asserting? I am unable to tell, and I suppose others may be as well. Maybe adding a quick text on what the example is asserting and tying this example to some of the security measures discussed in Section 10 may be helpful (for example, Section 10 talks about how an assertion can be restricted to a certain set of receivers (audiences). How- ever, the element in the example is empty. I guess it would be good if the example be a little more fleshed out and tied into Section 10 and/or portions of use- case scenarios discussed in Section 6. NITS: 1) Section 1, s/SPKI or extensions to the authenticated identity body [RFC3893]/ SPKI, extensions to the authenticated identity body [RFC3893], and SAML/ 2) In section 2, s/concocted/defined. "Concocted" is more of a colloquial term; "defined" or "used" fits much better here. 3) In section 2, s/moral equivalent/logical equivalent. 4) In section 4, first paragraph, s/regarding an assertion/an assertion 5) Section 6.1, first sentence: s/Bob, which/Bob, who 6) Section 6.2, s/user who routes its/user who routes his or her or alternatively, substitute with "user agent who routes its" Hope this is helpful. 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) --------------ms010607080101050209060804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MTAxNjQxNDZaMCMGCSqGSIb3DQEJ BDEWBBRzzK9mktLkRwNi1+QO+z+GFNNeQDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGALRb2mc1PQZ3axPKcvJYQuCB9jn1gkY03/WsA0HhJhB1xHMUlv6mR Iu1S6gr0ZFNO5v7GqKHpIZhpjqZYqnngL6SWpiLyk57eQXZtj/mJiKrfNDUXjhAPQNCkEVqZ FBDP7YYDJK2D/1y4xiyovPrrhnStr8Rad8psl/+xr2ZjPxcAAAAAAAA= --------------ms010607080101050209060804-- --===============0815647774== 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 --===============0815647774==-- From sip-bounces@ietf.org Wed May 10 13:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdseN-0005zB-Di; Wed, 10 May 2006 13:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdseM-0005z1-Ad for sip@ietf.org; Wed, 10 May 2006 13:39:02 -0400 Received: from mail.infointeractive.com ([207.231.225.15] helo=smtp.infointeractive.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdseL-0008TU-3I for sip@ietf.org; Wed, 10 May 2006 13:39:02 -0400 Received: from eng.infointeractive.com ([10.142.0.50]:53161 "EHLO eng.infointeractive.com") by mail.infointeractive.com with ESMTP id S835589AbWEJRi6 (ORCPT ); Wed, 10 May 2006 14:38:58 -0300 Received: from localhost (user: 'benoit', uid#6008) by eng.infointeractive.com id <221460-17632>; Wed, 10 May 2006 14:38:34 -0300 Date: Wed, 10 May 2006 14:38:34 -0300 From: David Benoit To: sip@ietf.org Message-ID: <20060510173834.GA10220@infointeractive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Sip] iLBC and early media X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, I have come across an interesting problem with iLBC. If I have a UAC that wants to make a call and offer to receive iLBC, I would have something like the following in an SDP: ... m=audio 29996 RTP/AVP 0 97 98 3 101 a=rtpmap:0 pcmu/8000 a=rtpmap:97 ilbc/8000 a=fmtp:97 mode=20 a=rtpmap:98 speex/8000 a=rtpmap:3 gsm/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 The iLBC mode (20 or 30) can't be determined until the answering SDP arrives. When I receive an early media RTP packet (as per RFC 3960) with the iLBC payload type, the only way I can determine the mode is to guess based on the packet size. This is made slightly more complicated because RFC 3952 allows multiple frames of audio to be sent in the same packet. While it seems that this is possible, it also seems to go against the intent of the offer/answer model as described in RFC 3264 whereby an endpoint advertises what it is willing to accept. With iLBC, we aren't able to limit what we can accept and must be willing to guess at what the answer SDP will actually contain. Have I missed a detail? Am I expected to guess? Is there something better I can do? David -- 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 Wed May 10 16:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvGE-0002Mk-HD; Wed, 10 May 2006 16:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdvGD-0002Mf-1I for sip@ietf.org; Wed, 10 May 2006 16:26:17 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdvGC-0007vr-QR for sip@ietf.org; Wed, 10 May 2006 16:26:17 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 73DC26C01D for ; Wed, 10 May 2006 16:26:12 -0400 (EDT) Subject: Re: [Sip] iLBC and early media From: "Dale R. Worley" To: Sip In-Reply-To: <20060510173834.GA10220@infointeractive.com> References: <20060510173834.GA10220@infointeractive.com> Content-Type: text/plain Date: Wed, 10 May 2006 16:26:12 -0400 Message-Id: <1147292772.14791.31.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: sip@ietf.org X-Mailman-Version: 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-05-10 at 14:38 -0300, David Benoit wrote: > m=audio 29996 RTP/AVP 0 97 98 3 101 > a=rtpmap:0 pcmu/8000 > a=rtpmap:97 ilbc/8000 > a=fmtp:97 mode=20 > a=rtpmap:98 speex/8000 > a=rtpmap:3 gsm/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > > The iLBC mode (20 or 30) can't be determined until the answering SDP > arrives. I'm not up on how SDP works, so I do not see where this problem comes from. Naively, it looks like any RTP with payload type 97 must be iLBC as well as mode=20 (whatever that is). Is the problem that the answerer can reject the mode=20 specification? (Presumably by omitting it in the answer.) If that is the case, there is an implicit requirement that the offerer must not only be willing to accept RTP with any specified encoding, it must also be willing to accept RTP with an encoding that would be generated by omitting any omittable modifiers. This looks like the critical standard: RFC 3264, section 6.1: The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer. 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 May 11 03:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe5S2-000102-P5; Thu, 11 May 2006 03:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe5S1-0000zt-Fj for sip@ietf.org; Thu, 11 May 2006 03:19:09 -0400 Received: from shardagate.techmahindra.com ([202.67.5.4] helo=shardagate.mahindrabt.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe5S0-0001ND-Ot for sip@ietf.org; Thu, 11 May 2006 03:19:09 -0400 Received: from imss-sh-isp1 ([10.5.2.145]) by shardagate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id k4B7J82a018837 for ; Thu, 11 May 2006 12:49:08 +0530 Received: from IMSS-1 ([10.5.3.66]) by imss-sh-isp1 with InterScan Messaging Security Suite; Thu, 11 May 2006 12:51:32 +0530 Received: from MBTSHEXCHANGE.mahindrabt.com ([10.5.5.2]) by IMSS-1 with InterScan Messaging Security Suite; Thu, 11 May 2006 12:48:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 May 2006 12:48:53 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcZ0yyidWUUommO6RmOLGTyNKCbsVg== From: "Manojkumar Patel" To: X-imss-version: 2.038 X-imss-result: Passed X-imss-approveListMatch: *@mahindrabt.com X-Spam-Score: 2.1 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Sip] (no subject) X-BeenThere: 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="===============0417039268==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0417039268== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C674CB.2978A6F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C674CB.2978A6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks & Regards =0D Manoj Patel MBT Ltd-Pune,=0D Next Generation Network,=0D Phone: +91-20-56018100 (Exnt: 2845)=0D Mobile: +91-9881403519 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tech Mahindra, formerly Mahindra-British Telecom. =0D Disclaimer: The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra. This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C674CB.2978A6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks & Regards
=A0
Manoj Patel
MBT Ltd-Pune,
Next Generation Network,
Phone: +91-20-56018100 (Exnt:= 2845)=0D
Mobile: +91-9881403519

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

Tech Mahindra, formerly Mahindra-British Telecom.


Disclaimer:


The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra.


This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
------_=_NextPart_001_01C674CB.2978A6F0-- --===============0417039268== 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 --===============0417039268==-- From sip-bounces@ietf.org Thu May 11 04:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6nH-0001Tw-At; Thu, 11 May 2006 04:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6nG-0001Tr-56 for sip@ietf.org; Thu, 11 May 2006 04:45:10 -0400 Received: from shardagate.mahindrabt.com ([202.67.5.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6nE-0005NI-IJ for sip@ietf.org; Thu, 11 May 2006 04:45:10 -0400 Received: from imss-sh-isp1 ([10.5.2.145]) by shardagate.mahindrabt.com (8.12.10/8.12.10) with ESMTP id k4B8j72a011408 for ; Thu, 11 May 2006 14:15:08 +0530 Received: from IMSS-1 ([10.5.3.66]) by imss-sh-isp1 with InterScan Messaging Security Suite; Thu, 11 May 2006 14:17:30 +0530 Received: from MBTSHEXCHANGE.mahindrabt.com ([10.5.5.2]) by IMSS-1 with InterScan Messaging Security Suite; Thu, 11 May 2006 14:14:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 May 2006 14:14:49 +0530 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Integreting between SIP Proxy and Credit Control client Thread-Index: AcZ0yyidWUUommO6RmOLGTyNKCbsVgACJRSQ From: "Manojkumar Patel" To: X-imss-version: 2.038 X-imss-result: Passed X-imss-approveListMatch: *@mahindrabt.com X-Spam-Score: 1.1 (+) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Subject: [Sip] Integreting between SIP Proxy and Credit Control 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="===============1532256884==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1532256884== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C674D7.2C8A0A9C"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C674D7.2C8A0A9C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C674D7.2C8A0A9C" ------_=_NextPart_002_01C674D7.2C8A0A9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI I have some query regarding the SIP Proxy and Credit control client(RFC 4006). I have plan to integrate credit control client with sip proxy . How can i integreate the CCA Client.Here I give u detailed arcitechture of my project.Andso i listed call flow diagrem. =0D =0D =0D =0D =0D =0D =0D =0D =0D CCCApp : Credit Control Client Application. CCSAppl: Credit Controm Server application =0D =0D =0D Thanks & Regards =0D Manoj Patel Next Generation Network,=0D Phone: +91-20-56018100 (Exnt: 2845)=0D Mobile: +91-9881403519 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tech Mahindra, formerly Mahindra-British Telecom. =0D Disclaimer: The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra. This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_002_01C674D7.2C8A0A9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI
 I have some query regarding the SIP= Proxy and=0D Credit control client(RFC 4006). I have plan to integrate credit control= =0D client with sip proxy . How can i integreate the CCA Client.Here I give u= =0D detailed arcitechture of my project.Andso i listed call flow=0D diagrem.
 
 
 
 
 
 
CCCApp : Credit Control Client=0D Application.
CCSAppl: Credit Controm Server=0D application
 
 
 

Thanks=0D & Regards

 

Manoj=0D Patel


Next= Generation=0D Network,
Phone: +91-20-56018100 (Exnt: 2845)=0D

Mobile:=0D +91-9881403519

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

Tech Mahindra, formerly Mahindra-British Telecom.


Disclaimer:


The contents of this E-mail (including the contents of the enclosure(s) or= attachment(s) if any) are privileged and confidential material of Tech= Mahindra and should not be disclosed to, used by or copied in any manner= by anyone other than the intended addressee(s). In case you are not the= desired addressee, you should delete this message and/or re-direct it to= the sender. The views expressed in this E-mail message (including the= enclosure(s) or attachment(s) if any) are those of the individual sender,= except where the sender expressly, and with authority, states them to be= the views of Tech Mahindra.


This e-mail message including attachment/(s), if any, is believed to be= free of any virus. However, it is the responsibility of the recipient to= ensure that it is virus free and Tech Mahindra is not responsible for any= loss or damage arising in any way from its use.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
------_=_NextPart_002_01C674D7.2C8A0A9C-- ------_=_NextPart_001_01C674D7.2C8A0A9C Content-Type: image/gif; name="clip_image001.gif" Content-Transfer-Encoding: base64 Content-ID: <343182008@11052006-064F> Content-Description: clip_image001.gif Content-Location: clip_image001.gif R0lGODlhsgKWAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAIAAgCt ApEAgQAAAAAAAP///wECAwL/RI6py+0PF5i02ouz3rzfCIbiSJaIh6bqyrauCceRS9f2jef6Hgj+ DwwKh8Si8RgM7Ja5HvIJjUqnVIGSic1qK86q91u8bsfksnnbBavV4rPbsI7L58m3/W5J0/fGNv4P GMikx1dYJ4hmqLhI5If4qEPIyOcIaXmJKTlJV4lZo7kZutbpWdoBKspmuspqh5r6RdqK8gpr+yQ7 21p7K5WrCxyswtsL9Sv8UazsiyxMvNzXLD19Cq1KXW2tPXSMHfi8feg9Pg0e/tNdfr6eTu66PtXu Po9ozk6fjIRgZfXArcDIXjR8lp6heiUQF8GFphJuk4esVpcD6IBMbFRRkUNu/wwfGexzZOPAjiTr 9WHQbx/AVBCdhUyS0UcaSTMNiRTSsiQPY/y49fR5k6POoXgkWowp81ZOYAjDHEWKNKhPTkSL8tTU A1TWQkuremVhdCrUUF1nSaT5NCnOp1knum0LN+XYa1/PENsK1KlUcXX7DtKHMS1Lknf11FS7Vu2+ jBcRN/45p6zfFLwex0SLOPLkzZEAZzaslLAvwQnCLP6cFq/juXQ5Z6k81vJlSq5r0zh7GrJusqJH o36Z+HfmpIep2sZSuXQS5ctzy5F8vG9YyKBtQV/VNLXgwDCjVgRdXHP0JdOFD68ufrx6DeW372XW EaHl8Nzdrz4v+/n6zsC92//fPsp+AubhGWPdwXJdQy+d5s8/uTlHkUwUPQhgHAmudxCDKEk4oYYR WjhgiHD0Rx1rk1zoyXvWnSjiJ/DA1yKGJy3QXDGVoGhXPi+SqBEGOA7liIrWxbifkAjmcYA0J1Bg 5IlN4oTkjzotOcGTvBGpnpWbiKGAkglUuaM2XH6JZZVkaslimdGhGZABMrwJJwhhWqNEnHbeiWec c+pTUp5+/gkoBHuG5GaXzTQwqDJ1SqAmook20tujkko4KZRmUunMmZUeeWmSjWq6KTqRhrrnh6H6 gWkwmLJJqhVRqlkoF626Gt+spbLa4wdK6uigc75teiOsQeIy4TlSQoKrrV7/mArsqNwlKyaslBXI LDTHeqRsmNVOeq1JJKoILRXdcpadib2M+022O24rKbqAlAfunO76Ve6L81qlLjzsPnrvHdMZxuxK b3HohK+KSkuLPjR9CFeHBZva1rLO5itmuHv0+05IEM6mWMH3/WQxpAhno7B2DBrY8UbBHsorTitR wlwVIWs8K8ZvhAXwyfcR8ta+Q47MATg9e8zxyyKh6mlESY8I0nCcUIzOzPrV2h99H7ul3T1Ab2AO 0fblt1s8TJKp9JLw2gQ1pa3a7Ma/FcoF1WNSh7E11zx6HTfIYkkcaN8jFBi2hWn3U/PEwen9MVur qTa3RXWzR/PV5yFOOd+M/5b9slP4zcSwz05H7fJinDfueamGR60hhxYppxLEAz/0eAZNQRjhxqu/ LnGnbN9gKG4Qo0x0eyjvLPcypct7+rIHkro7kIVzsbSqS59NMN6B7+0f5WCf23hrBL2HHvOx+/h8 HrsSePfnruOyd/GJG989GM2XAW7M4o+P/v0MtWf9f01/R5rffY575VtI/NaFv/ydKnnZa0zwBkia 4YXNfTY6YO72N7j0JJBpC6RaI2h0O9SJUH0bUhvqatc50llQZgzMIIw2uEJxtVBfy2NHDMXmQRfK b4NMKuD3KhU+G/oQHzcMx/z6NER6FFFjBjPiEo0xQx3yiYccbFYOpaiUJ/8q5IpYxCEP/QbG6BGx ixVM4jy0aC0qqrEJZCTg2qLYRkutcY4viKN10EgoLtoxj3Ts4zD2yBI8jsSAgIzCEf2YJZ68jXuZ g58Z3SFIGyFykiT7n7nOtUgERVJkGCzkFikJypZhjx8hw0oND6eRTQqlk57kYyhfWcVRqgZB9YHg 9TihSjkSspWuhCUo6wXAGo0QdMRkGOEIhkqQpfBhQjqetuBYyEP6cjLArJwDi5Y10bGGZ5J73yhy yZcf8nKQ05xkNeeTzOJQcHvcXF1s6vdIcoBzMOX8JY9SIkAAqZNjldMn6OYzSwuFEYzQBKQ06/kV YKKnnRHsZj/z5tDtxQL/obIbJzkpOkeFHuiaO2NL7WbD0BIdk5Q9caYhMSpKi4oKpX3EmYeYGUJ3 LqekDjNh9QLWIbW1zjgsBZNKV9lTNQrvp1MM6jxFcdCg6jGZRL0oRo96JaVS8S5NhaJSobolqQq1 qjztaWGKdbuAluYgWtMqDLmqQZbChpifCY/PYphUsyoRrVMzKuC8mR+t3DI0ck0gVk131XuWdCqY yYsR++pXuoIosJZk6iXXAp6amHSiiB3fX5HHWM3V8pT/ex1M9xqgysYuQ/aTmR3jmsjGcvaxWfuN 1XDZANE2ilqjiCNqx1PNTAotZod5rWYYINvZfqu2ZLztmu760LxiD50i/7WJ7owbXOwA7iaXPWlm LRm+7NYSa8q05WILlaroDshtMVWdeVmbLeja5qsL21Zp8XlCUkoWTW0wm3rFiyyFUUgx/DWPDu/r Gi0WNk1mQhJ+BUQ9meYsn1IEMLnkNcpcMclHDj5wxhqLNe4Grrqf9Kq2cMqqdITXwvS6q9eqY8ou VpiaipXHiEnslQQ/rL/MxeKKS0zXnIgRxkQhLW9z+iAGN1iqHHbubW7MYzbSsrhEbjHvkHyzgUq5 BKyAVpE7rFYn4+DFLPbkfZN1ZSyjNMwX48GOcRzNKis2tHbNMXKg/JpWfnnN3huzlt/8YC+rmc6U bTNau3Vm5+lZuny+oP+H3UwGLi+VyYQutAyvW9V5KVqcaW60o1+YZUS3Dc51HLSCLu3FQ/+5KJxe AZkxnQlQhzrTo/5DoOUp5z2r2qp+5uoRJ60OYoE1vqO7pcr6XIpTww7STZUmriPCPrZSR25kXZZD 5jxrWova1pd4NbLvqVzd6PXZwE5RtKXNampnotQKjHD/BnuVWHQ71d8u6rQj3RBy+1SzEZbpgmDy OyGjutrtdne44Y0da1u63t61aXA8a16J+pvd/aYbsYnq4GMzfLOZXK01FSfBVU+84br8d7Gl5xLV Vny1mestxlk4cI477uE/hbLA84vt2EwOlcw1uaG9rXKgehziXjJLsmf/7hh2bvTEJ143v3PecTtr +lAvd7UxDMZbuDWnZ/I9SgpvXqWipDTn8p7SncvR9Auzg+A3l/ggpof0pD/169gIu13WRXaUg5dt vUt7OMc85bzfSYlJLSLtwDd3vUfA7itPMn7dngg9A9dfJSR81w2/XsT/xdOGcgWoCE8ryFvY7JOv 9NjojnbMZ17zJJb8lmOtK39tXeWPJz1u+yVscG887a13/evf7ulgi370tucx5zvted2Lvva9z5Lp p5V7nGOe+MXHkJRiL+ajL7/5vT++3ZI/e6Qzn/pFuhD0Fy59x3O/+b+vKParLfj0q3/81C9/uU/L /vjL3023Qf3879/+qZZ8v5f477/rEb9/TuV/A2h4EheADkeACUh6I1Zf9qeADwh50ZM0B8hJEGiB SeYpVEKBOneBHbh5dXd+HiiCwSUBG6h2I4iCiOUowZeCLShXDuCALiiDomWCdzeDN6hVNVh4OMiD TRaCPQiE9aSDKxWERUhRQygTRqiEQhiDS+iE5tSETyiFGRWFU2iFZ/WDV6iFdYOEvLeFX8iFVQiG Y/gp6meGZCN/BQAAOw== ------_=_NextPart_001_01C674D7.2C8A0A9C-- --===============1532256884== 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 --===============1532256884==-- From sip-bounces@ietf.org Thu May 11 07:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe983-0008Ec-OS; Thu, 11 May 2006 07:14:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe981-0008EX-QD for sip@ietf.org; Thu, 11 May 2006 07:14:45 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe97z-0003Fb-Ep for sip@ietf.org; Thu, 11 May 2006 07:14:45 -0400 Received: by tutpro.com (Postfix, from userid 65534) id A22EA1400F1; Thu, 11 May 2006 14:14:37 +0300 (EEST) Received: from rautu (polymer182.gprs.dnafinland.fi [62.78.110.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 591221400A5 for ; Thu, 11 May 2006 14:14:31 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 4246BF03FA; Thu, 11 May 2006 14:14:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17507.7302.227190.439598@rautu.tutpro.com> Date: Thu, 11 May 2006 14:14:14 +0300 From: Juha Heinanen To: sip@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Sip] outbound i-d update? X-BeenThere: sip@ietf.org X-Mailman-Version: 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 would be important to get outbound i-d out as rfc asap. i don't think there are many things that need to be fixing in -03, but i would like to see them done now rather than waiting for yet another ietf meeting. one of the issues is the notion of "primary" and "backup" proxies that should go away. it should suffice that UA is configured with at least two outbound proxies, which may have same or different priority. have authors of outbound i-d kept a list of other outstanding issues? -- 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 May 11 09:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAye-0004L0-Ss; Thu, 11 May 2006 09:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAye-0004Kv-5v for sip@ietf.org; Thu, 11 May 2006 09:13:12 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAyb-0000ZC-HJ for sip@ietf.org; Thu, 11 May 2006 09:13:12 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4BDD8bF016808; Thu, 11 May 2006 15:13:08 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4BDD8PN030643; Thu, 11 May 2006 15:13:08 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 15:13:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 May 2006 15:13:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial review of sip-saml draft Thread-Index: AcZ0UOPT/Os+alPiT6GAXCG+uo/9HgAqbYNA From: "Tschofenig, Hannes" To: "Vijay K. Gurbani" X-OriginalArrivalTime: 11 May 2006 13:13:08.0259 (UTC) FILETIME=[A56CCF30:01C674FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: IETF SIP List Subject: [Sip] AW: Initial review of sip-saml 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: , Errors-To: sip-bounces@ietf.org Hi Vijay,=20 thanks for your review.=20 =20 > Hannes: Here are initial comments based on the review of sip-saml > I-D (-05). Thanks for getting this out. >=20 > I hope these are helpful. I have divided them into a nits > section (further down below) and a substantive comments > section, which follows next. >=20 > 1) In Section 1 itself, you may want to give a reference for > "authorization certificates". I presume you meant rfc3281? > Also, a reference for SPKI may help. I presume you meant > rfc2692 and rfc2693. However, these are experimental RFCs, > and I am curious whether there are any deployments. These > do make for interesting reading, though (especially rfc2693). You are right that a few references would not hurt. I don't know a lot about the deployment of attribute certificates.=20 >=20 > 2) I would actually put the current Section 3 *after* the > current Section 4. The reason is that in Section 4, you define > the terms (SAML profile, SAML binding, etc.) that are used > liberally in Section 3. Thus, if you put Section 4 first, your > reader will have a better idea of what you are talking about. That seems to be OK for me.=20 >=20 > 3) I believe that the first paragraph in Section 5 is very > important since it provides guidance on why this specification > is needed at all. Maybe some terse editing to further highlight > this will help. Something along the lines of: > Current use of SAML is strongly tied to its use with HTTP- > based web browing. This is a natural outcome of its > evolution. However, the next step in this evolution is using > SAML in other contexts and protocols, such as Internet session > signaling and SIP. While SIP is closely related to HTTP, it > is distinct enough that a new SAML profile or profiles will > need to be specified. Fortunately, this should not cause a > problem since both SAML and SIP are designed to be extensible > protocols. Sounds good to me.=20 It took me also some time to understand the details of the SAML profiles and bindings.=20 To be honest: Working together with the SAML authors helped me a lot.=20 >=20 > 4) Section 6.1. So, when I read the description, I am left to > wonder what are Alice's "profile attributes" that the PSTN/SIP > gateway provider imparts to Bob. Could you give some examples? > Otherwise, all that I can think of is Alice's identity, which > can be imparted to Bob. And doing so will not require SAML. These examples are taken from the trait-based authz draft.=20 When we wrote the document it seemed to be a good idea to include these examples. In the meanwhile I am not sure anymore given that we have documents that describe the aspects in more detail.=20 For now, I still would keep them in there.=20 >=20 > 5) In Section 6.3, it is stated that "The Offer contains > information about the three parties...". As far as I can see, > the offer contains information about two parties: the merchant > (Bob) and the user (Alice). The third party -- Payment=20 > Provider -- > is brought into the equation with the Receipt (in step 4). You might want to take a look at the SIP Payment draft. The offer indicates the merchant, the customer and the preferred payment provider(s).=20 >=20 > 6) In section 9, there is an example of a signed SAML assertion. > What is it asserting? I am unable to tell, and I suppose > others may be as well. Maybe adding a quick text on what the > example is asserting and tying this example to some of the > security measures discussed in Section 10 may be helpful (for > example, Section 10 talks about how an assertion can be > restricted to a certain set of receivers (audiences). How- > ever, the element in the example is > empty. I guess it would be good if the example be a little more > fleshed out and tied into Section 10 and/or portions of use- > case scenarios discussed in Section 6. We initially included it to give the reader an idea what a SAML assertion is. =20 I don't want to put an assertion based on a specific extension (such as a payment assertion) in there.=20 Maybe we can put some authentication traits into the example.=20 > NITS: >=20 > 1) Section 1, > s/SPKI or extensions to the authenticated identity body=20 > [RFC3893]/ > SPKI, extensions to the authenticated identity body=20 > [RFC3893], and > SAML/ >=20 > 2) In section 2, s/concocted/defined. "Concocted" is more of a > colloquial term; "defined" or "used" fits much better here. >=20 > 3) In section 2, s/moral equivalent/logical equivalent. >=20 > 4) In section 4, first paragraph, s/regarding an assertion/an=20 > assertion >=20 > 5) Section 6.1, first sentence: s/Bob, which/Bob, who >=20 > 6) Section 6.2, s/user who routes its/user who routes his or her > or alternatively, substitute with "user agent who routes its" We will fix it.=20 >=20 > Hope this is helpful. Thanks a lot.=20 Ciao Hannes >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 11 23:30:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeOJM-0001qD-5e; Thu, 11 May 2006 23:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeOJK-0001q8-UM for sip@ietf.org; Thu, 11 May 2006 23:27:26 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeOJJ-00071w-Nj for sip@ietf.org; Thu, 11 May 2006 23:27:26 -0400 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4C3RLqA024646 for ; Thu, 11 May 2006 22:27:22 -0500 (CDT) Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 May 2006 08:57:20 +0530 Message-ID: <3BE48DD0EC7D3948BC183931D9150C21023D9964@ii0015exch001u.iprc.lucent.com> From: "Shyamsundar, Purkayastha (Purkayastha)** CTR **" To: "'sip@ietf.org'" Date: Fri, 12 May 2006 08:57:20 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Sip] Header Encoding for WWW-Authenticate X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org According to standard ABNF defined in RFC3261 all the SIP headers are encoded in such a way the the terminating CRLF characters appear after the complete header ( that including the header name followed by COLON & parameters). However , recently while implementing and testing a UA for registration procedure with WWW-Authenticate I have noticed that this header is encoded with CRLF appearing after every header parameter. This happens only with WWW-Authenticate and not with any other header. I am testing this UA with a IMS specific implementation ( CSCFs) for transmission of SMS over SIP . and this has been tested successfully with some conmmercial SMS clients as well. However in the case of my UA the parser is failing because I am using the CRLF to seperate the headers and my parser is treating the individual parameters of WWW-Authenticate as SIP headers hence failing. Now my query is wheather the WWW-Authenticate should follow the same standard ABNF defined for all the SIP headers? Or is it the case that for IMS specific implementation it is encoded in this way? thanks in advance Shyam _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 12 00:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FePJE-0008NH-Fx; Fri, 12 May 2006 00:31:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FePJD-0008N9-CL for sip@ietf.org; Fri, 12 May 2006 00:31:23 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FePJB-0001V4-1N for sip@ietf.org; Fri, 12 May 2006 00:31:23 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.03) id AF83023C; Fri, 12 May 2006 00:30:59 -0400 Message-ID: <005201c6757c$df23aed0$800101df@acmepacket.com> From: "Bob Penfield" To: , "Shyamsundar, Purkayastha \(Purkayastha\)** CTR **" References: <3BE48DD0EC7D3948BC183931D9150C21023D9964@ii0015exch001u.iprc.lucent.com> Subject: Re: [Sip] Header Encoding for WWW-Authenticate Date: Fri, 12 May 2006 00:31:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: SIP-Implementors X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Questions like this really belong on the Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors If the line following the CRLF begins with whitespace, that line is a continuation of the same header. Section 7.3 of RFC 3261 refers to this: 7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Shyamsundar, Purkayastha (Purkayastha)** CTR **" To: Sent: Thursday, May 11, 2006 11:27 PM Subject: [Sip] Header Encoding for WWW-Authenticate > > According to standard ABNF defined in RFC3261 all the SIP headers are > encoded in such a way the the terminating CRLF characters appear after the > complete header ( that including the header name followed by COLON & > parameters). > > However , recently while implementing and testing a UA for registration > procedure with WWW-Authenticate I have noticed that this header is encoded > with CRLF appearing after every header parameter. This happens only with > WWW-Authenticate and not with any other header. > > I am testing this UA with a IMS specific implementation ( CSCFs) for > transmission of SMS over SIP . and this has been tested successfully with > some conmmercial SMS clients as well. However in the case of my UA the > parser is failing because I am using the CRLF to seperate the headers and > my > parser is treating the individual parameters of WWW-Authenticate as SIP > headers hence failing. > > Now my query is wheather the WWW-Authenticate should follow the same > standard ABNF defined for all the SIP headers? > Or is it the case that for IMS specific implementation it is encoded in > this > way? > > > thanks in advance > Shyam > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 12 03:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeRgH-0007iP-2F; Fri, 12 May 2006 03:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeRaM-0007Bh-VO for sip@ietf.org; Fri, 12 May 2006 02:57:14 -0400 Received: from mail2.abbeynet.it ([151.9.176.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeRMQ-0007x6-Cv for sip@ietf.org; Fri, 12 May 2006 02:42:52 -0400 Received: from mail2.abbeynet.it (localhost.localdomain [127.0.0.1]) by mail2.abbeynet.it (Postfix) with SMTP id 182F050B25; Fri, 12 May 2006 08:42:49 +0200 (CEST) Received: from [192.168.0.74] (marco-ambu.localnet [192.168.0.74]) by mail2.abbeynet.it (Postfix) with ESMTP id 7533F50B25; Fri, 12 May 2006 08:42:42 +0200 (CEST) Message-ID: <44642E5D.6050502@abbeynet.it> Date: Fri, 12 May 2006 08:42:37 +0200 From: Marco Ambu User-Agent: Mozilla Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Shyamsundar, Purkayastha (Purkayastha)** CTR **" Subject: Re: [Sip] Header Encoding for WWW-Authenticate References: <3BE48DD0EC7D3948BC183931D9150C21023D9964@ii0015exch001u.iprc.lucent.com> In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C21023D9964@ii0015exch001u.iprc.lucent.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: "'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 Shyamsundar, Purkayastha (Purkayastha)** CTR ** ha scritto: > According to standard ABNF defined in RFC3261 all the SIP headers are > encoded in such a way the the terminating CRLF characters appear after the > complete header ( that including the header name followed by COLON & > parameters). > Not true! RFC 3261 - ABNF: WWW-Authenticate = "WWW-Authenticate" HCOLON challenge ; then CRLF challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge so CRLF appears after the "complete header" as in all the other headers defined in 3261 (see also the examples in rfc 3261 and 3665). Example: WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 // [HERE IS CRLF HEADER LINE TERMINATOR - AFTER CHALLENGE] > Now my query is wheather the WWW-Authenticate should follow the same > standard ABNF defined for all the SIP headers? > If follows the same standard but is cannot be used as multiple header even if is a comma-separated list of values, as described in 7.3.1: [...] It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. -- Marco Ambu Abbeynet s.p.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 Fri May 12 06:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVI2-00046r-07; Fri, 12 May 2006 06:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVHz-00046m-R6 for sip@ietf.org; Fri, 12 May 2006 06:54:31 -0400 Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVHy-0003QL-Gw for sip@ietf.org; Fri, 12 May 2006 06:54:31 -0400 Received: from Nataraju ([192.168.3.66]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k4CAs6W04335; Fri, 12 May 2006 16:24:06 +0530 From: "Nataraju A B" To: "'Marco Ambu'" , "'Shyamsundar, Purkayastha \(Purkayastha\)** CTR **'" Subject: RE: [Sip] Header Encoding for WWW-Authenticate Date: Fri, 12 May 2006 16:23:17 +0530 Message-ID: <006e01c675b2$482858b0$4203a8c0@Nataraju> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <44642E5D.6050502@abbeynet.it> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: Marco Ambu [mailto:marco.ambu@abbeynet.it] Sent: Friday, May 12, 2006 12:13 PM To: Shyamsundar, Purkayastha (Purkayastha)** CTR ** Cc: 'sip@ietf.org' Subject: Re: [Sip] Header Encoding for WWW-Authenticate Shyamsundar, Purkayastha (Purkayastha)** CTR ** ha scritto: > According to standard ABNF defined in RFC3261 all the SIP headers are > encoded in such a way the the terminating CRLF characters appear after the > complete header ( that including the header name followed by COLON & > parameters). > Not true! RFC 3261 - ABNF: WWW-Authenticate = "WWW-Authenticate" HCOLON challenge ; then CRLF challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge so CRLF appears after the "complete header" as in all the other headers defined in 3261 (see also the examples in rfc 3261 and 3665). Example: WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", stale=FALSE, algorithm=MD5 // [HERE IS CRLF HEADER LINE TERMINATOR - AFTER CHALLENGE] > Now my query is wheather the WWW-Authenticate should follow the same > standard ABNF defined for all the SIP headers? > If follows the same standard but is cannot be used as multiple header even if is a comma-separated list of values, as described in 7.3.1: [...] It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. [ABN] any header can always be folded over multiple lines by inserting a leading space after CRLF. (As paul mentioned in his earlier mail). The catch is if we miss the leading SPACE in the new line, lead to syntax error.... -- Marco Ambu Abbeynet s.p.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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 12 19:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feh1J-0001Py-OY; Fri, 12 May 2006 19:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feh1H-0001Pl-Ld for sip@ietf.org; Fri, 12 May 2006 19:26:03 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feh1G-0001di-DJ for sip@ietf.org; Fri, 12 May 2006 19:26:03 -0400 Received: by py-out-1112.google.com with SMTP id e30so667323pya for ; Fri, 12 May 2006 16:26:01 -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=FHjPzB7PbGjk+A+63OLsrgwFZMSa289izFCc55LvW9Y6ptSucl2uhx0Jc1uwLsUcl+utf4pQZ2SK4553LGHFjsSqWeSPuJZmGmZ4w2a4GmKvK5R0QQ3sv5BFyjCQH2eevI/wJSpvDHMODQh8d2t6m0Uq48TD/one4ROIIoW43Oo= Received: by 10.35.53.18 with SMTP id f18mr8555pyk; Fri, 12 May 2006 16:26:01 -0700 (PDT) Received: by 10.35.54.17 with HTTP; Fri, 12 May 2006 16:26:01 -0700 (PDT) Message-ID: <953beacc0605121626k2b5bec94x1077faf0c1aecde0@mail.gmail.com> Date: Fri, 12 May 2006 16:26:01 -0700 From: "Rohan Mahy" To: "Juha Heinanen" Subject: Re: [Sip] outbound i-d update? In-Reply-To: <17507.7302.227190.439598@rautu.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17507.7302.227190.439598@rautu.tutpro.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, drage@lucent.com, dean.willis@softarmor.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 Juha, I have been keeping a list of comments received so far. I am waiting for the chairs at this point. thanks, -rohan On 5/11/06, Juha Heinanen wrote: > it would be important to get outbound i-d out as rfc asap. i don't > think there are many things that need to be fixing in -03, but i would > like to see them done now rather than waiting for yet another ietf > meeting. > > one of the issues is the notion of "primary" and "backup" proxies that > should go away. it should suffice that UA is configured with at least > two outbound proxies, which may have same or different priority. > > have authors of outbound i-d kept a list of other outstanding issues? > > -- 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 Mon May 15 09:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdAR-0005RO-F5; Mon, 15 May 2006 09:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdAP-0005Qi-Uk for sip@ietf.org; Mon, 15 May 2006 09:31:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfdAO-0003l5-1n for sip@ietf.org; Mon, 15 May 2006 09:31:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 15 May 2006 06:31:19 -0700 X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="1806215645:sNHT38836950" 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/8.12.11) with ESMTP id k4FDVIGi008135; Mon, 15 May 2006 06:31:18 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4FDVIsF013176; Mon, 15 May 2006 06:31:18 -0700 (PDT) Received: from [10.43.1.79] ([10.61.65.86]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 06:31:17 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F26670896A542@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F26670896A542@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1ABF640C-E57E-41FC-AF7B-C64E78A64EA2@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Sip] Connected-identity and changing the To header field ina response Date: Mon, 15 May 2006 05:48:17 +0200 To: Roland Jesske , "Christer Holmberg (JO/LMF)" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 15 May 2006 13:31:17.0772 (UTC) FILETIME=[D87A4CC0:01C67823] DKIM-Signature: a=rsa-sha1; q=dns; l=18379; t=1147699878; x=1148563878; c=relaxed/simple; s=sjdkim6001; 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]=20Connected-identity=20and=20changing=20the=20To=20header= 20field=20ina=20response; X=v=3Dcisco.com=3B=20h=3DXH+zhU807AfP85yiy9g/rH7tJbM=3D; b=qbywOUp5GxIxjhemqGNFBsAEcAg7yZ+vldKLfKrLgCaS80sZjdSvwJNY18ngTx0pZdCU5/yH ZOqxFey5okrG832tdX8Wai+8L2BfGVdnOHOKtcFeTKzkFlRWPpkopwaZ; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Cc: sip@ietf.org, John Elwell , 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 Can someone explain to me why it is that the TIP requirement can not =20 be solved with the connected-identity draft? I do understand it may =20 not be the way some people desire to solve this problem but first of =20 all I am just trying to understand what parts of the requirements we =20 can't meet with this. Thanks, Cullen On Apr 5, 2006, at 10:48 PM, Elwell, John wrote: > Roland, > > Yes, there was indeed a misunderstanding, but my draft was not =20 > written with > TISPAN requirements in mind. It was written to solve the problem of > authenticated identity, or rather to extend the present concept of the > Identity header to mid-dialog requests and show how that can be =20 > used to > solve certain problems. > > The Terminating Identity Presentation (TIP) requirement from TISPAN =20= > needs to > be addressed by some other means. I don't think modifying the To =20 > header is > appropriate. Whereas RFC 3261 anticipates deprecating fixed To/=46rom =20= > header > field URIs throughout a dialog (i.e., it anticipates that these =20 > will be > allowed to change mid-dialog), it says nothing to warn of any =20 > future removal > of the requirement that the To header field URI in the response be =20 > the same > as that in the request. > > Therefore it seems that whatever solution you adopt for solving the =20= > TISPAN > TIP problem, it would have little in common with the connected-=20 > identity > draft. > > John > > >> -----Original Message----- >> From: Roland Jesske [mailto:roland.jesske@web.de] >> Sent: 05 April 2006 14:33 >> To: Christer Holmberg (JO/LMF); Elwell, John; Peterson, Jon; >> sip@ietf.org >> Subject: RE: [Sip] Connected-identity and changing the To >> header field ina response >> >> John, >> there it looks like a misunderstanding. Thought all >> requirements from IETF and TISPAN can be solved within your draft. >> >> As you saw he additional connected identity is a requirement >> comming from TISPAN and that was discussed in also in >> Vancover. In draft-sasaki-sipping-tispan-adhoc-summary-00.txt >> it is mentioned. >> >> Terminating Identification Presentation(TIP)- The working group >> requests that this requirement be better defined and =20 >> documented. >> It is also suggested that TISPAN consider reading >> draft-rosenberg-sip-identity-privacy-00 as it may solve the >> problem of calling into an 800 number, getting an operator, and >> being able to call back that operator and still protect the >> privacy of the operator. >> In addition, work is progressing on >> draft-elwell-sip-connected-identity-00. >> >> So using the PAI does not need to go deeper into >> draft-rosenberg-sip-identity-privacy-00, but looking into your draft. >> And looking within your draft using the dialogUriChange >> element we thought we have the solution if this can be done >> within the final Response of the initial INVITE. >> >> Best Regards >> >> Roland >> >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: "Elwell, John" >>> Gesendet: 05.04.06 14:56:20 >>> An: sip@ietf.org >>> Betreff: RE: [Sip] Connected-identity and changing the To >> header field ina response >> >> >>> Christer, >>> >>> This "additional connected number" is not a requirement >> that I have been >>> trying to address. Was this among the requirements that >> TISPAN brought into >>> the IETF recently? >>> >>> John >>> >>>> -----Original Message----- >>>> From: Christer Holmberg (JO/LMF) >>>> [mailto:christer.holmberg@ericsson.com] >>>> Sent: 05 April 2006 08:34 >>>> To: Elwell, John; Peterson, Jon; sip@ietf.org >>>> Subject: RE: [Sip] Connected-identity and changing the To >>>> header field inaresponse >>>> >>>> >>>> Hi, >>>> >>>> In PSTN terms we are talking about that the TO header shall >>>> be mapped to >>>> the additional connected number, and that does NOT need to be >>>> authorized >>>> in the same way as the connected number. >>>> >>>> And, whether the interworking node sends this value to PSTN >>>> is of course >>>> based on local policy, based on trust etc. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ________________________________ >>>> >>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>> Sent: 5. huhtikuuta 2006 10:01 >>>> To: Peterson, Jon; sip@ietf.org >>>> Subject: RE: [Sip] Connected-identity and changing the To >> header field >>>> inaresponse >>>> >>>> >>>> Jon, >>>> >>>> Thanks for this excellent summary of the issue, which I fully >>>> agree with >>>> and which unfortunately seems to need restating at regular >>>> intervals. It >>>> appears that the chief motivation of those asking for >> something in the >>>> response is to facilitate interworking with PSTN (by >>>> including it in the >>>> 200 response so that it can be mapped directly to the >> PSTN "connected" >>>> message). As you say, such a response is always going to be >>>> unauthenticated, and I don't think that meets the >> requirements of PSTN >>>> interworking. Far better to figure out a way of using an >> authenticated >>>> connected identity in an UPDATE message for mapping to >> PSTN connected >>>> identity. >>>> >>>> Of course, in trusted networks there may be other means for >>>> ensuring the >>>> authenticity of an identity in a response, just as there is >>>> in a request >>>> using P-Asserted-Identity. Unfortunately RFC3325 is >> unclear on the use >>>> of PAI in responses, although in practice I think it is >> used and is >>>> probably OK if the last hop is secured by TLS so that previous >>>> authentication of the UAS can be relied on for making the >> assertion. I >>>> think if those trusted networks really need a solution >> for response >>>> identity, PAI would be a better avenue to explore (taking >> into account >>>> the risks). But not for the Internet. I am becoming more and more >>>> convinced that diluting the connected-identity draft with a weak >>>> solution for response identity would be the wrong way to go. >>>> >>>> John >>>> >>>> >>>> ________________________________ >>>> >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >>>> Sent: 05 April 2006 02:05 >>>> To: Elwell, John; sip@ietf.org >>>> Subject: RE: [Sip] Connected-identity and changing the To header >>>> field in aresponse >>>> =09 >>>> =09 >>>> Yes, I was asked for clarification on this point after the >>>> meeting, and I'll be providing it here. As you surmised, it >>>> is not that >>>> RFC3261 relies on the addr-spec of the To or =46rom header field = for >>>> transaction identification, or something. In fact, I would have >>>> essentially the same concerns about any proposal that provided an >>>> additional header (say, a 'Connected-Party' header) in >> responses to >>>> dialog-forming requests which was understood to clobber >> the To header >>>> field and identify the AoR of the party who was reached after >>>> retargeting of the request took place. >>>> =09 >>>> Starting with the goals of this approach: what sort of UAC >>>> decisions or behavior do we hope to enable through >> sending a response >>>> with a modified To header field? As far as I can >> understand, we either >>>> want to render this AoR to the user of a UAC (so the user >> can react in >>>> one way or another), or input the AoR to some sort of >> policy manager >>>> (e.g. blacklist/whitelist) that might make a decision >> about whether or >>>> not the session should continue -prior- to session >>>> establishment. If we >>>> don't care about this occurring prior to session establishment, of >>>> course, then we could go with the connected-identity >> draft as it is >>>> written today. >>>> =09 >>>> A little refresher on my sipping-retarget draft: The core >>>> problem with any scheme for connected party is figuring >> out how you'd >>>> decide whether or not a particular respondent is authorized. >>>> This is the >>>> argument of 2.2.1 of sipping-retarget, the "unanticipated >> respondent" >>>> problem. When we think about what sorts of policy decisions >>>> we expect a >>>> human or automata to make when receiving a response with identity >>>> information, we have to acknowledge that the UAC has no >> way of knowing >>>> which respondents are or are not authorized to respond to the >>>> request in >>>> question. Since the UAC has no insight into any >> retargeting that has >>>> taken place, the UAC has to assume that virtually any >> response is a >>>> potentially legitimate one. As such, there is little room for any >>>> meaningful policy decision when receiving a response. >> This problem is >>>> further compounded by the fact that the UAS may have >> several possible >>>> legitimate AoRs it could claim (I have a UA that >> registers its contact >>>> address under 3 separate SIP services simultaneously), and of >>>> course the >>>> fact that AoRs may be pretty uninformative (e.g. >>>> sip:user31@freesipservice.example.com), all of which complicate >>>> authorization decisions. Solving this problem is on the same >>>> footing as >>>> solving the request-history problem set. >>>> =09 >>>> With that background, the problems with providing this connected >>>> party information in responses (via the To header or what >>>> have you) are >>>> roughly as follows: >>>> =09 >>>> a) The "unanticipated respondent" problem is especially an issue >>>> for response identity because not all responses are >> success responses. >>>> If you end up connecting to a party (receiving a 200), you can >>>> potentially rely on human factors to help you identify who you are >>>> talking to (after all, Carol can always answer Bob's phone >>>> regardless of >>>> who SIP thinks you connected to) and/or use the connected party >>>> information to change how you might address the party on the >>>> other side. >>>> With a 403 response, you are in a very different >> predicament - how is >>>> UAC or user behavior supposed to change based on the connected URI >>>> attributed to a 403, given the unanticipated respondent >> problem? For >>>> provisional responses, the issues become even worse - we >> then get into >>>> the wonders of forking, multiple provisional responses >> from multiple >>>> sources asserting different To header fields - in short, >> nothing which >>>> makes it any easier to render a "responding" AoR to a user, >>>> for example. >>>> Response identity, in so far as it deals with non-final, >>>> non-successful >>>> responses, opens up the "unconnected party" problem set. I >>>> think this is >>>> just the wrong framing of the problem. You want to know who you >>>> connected to, not who you didn't connect to. >>>> =09 >>>> b) Getting a signature over the To header field in responses >>>> would be difficult. In full awareness of Mr. Elwell's >> note below that >>>> certain parties are interested in "(unauthenticated) identity in a >>>> response", if this information is going to be put to any >>>> purpose, cause >>>> any change in human or UAC behavior, I have a hard time seeing how >>>> anyone could defend it being unsecured. If you want a human or an >>>> automata to make a policy decision based on the AoR in >> the To header >>>> field of the response, some sort of response identity >>>> signature would be >>>> necessary to prevent obvious impersonation attacks >> designed to thwart >>>> authorization decisions. With all due respect to the authors of >>>> draft-cao-sip-response-identity/auth, I'm not sure this problem is >>>> readily solved. Making sure that an appropriate >> authentication service >>>> is in the path of responses is problematic, since responses must >>>> traverse exactly the same path as requests. I played around >>>> with this a >>>> lot in the early phases of SIP identity, and at the end >> of the day, I >>>> had to conclude that the only way to make this work was >> to eliminate >>>> retargeting. Since providing connected-identity in >> responses assumes >>>> that retargeting has taken place, it wouldn't exactly be >>>> getting off on >>>> the right foot. Constraining inbound request routing to a >> domain such >>>> that responses will traverse an authentication service, or >>>> forcing a UAS >>>> to participate in the Identity scheme, is likely to >> require mandatory >>>> option-tags or comparable mechanisms that will limit the >> applicability >>>> of response identity and more or less eliminate its >> opportunistic use. >>>> =09 >>>> c) The inability to reject a response. Take the easiest case - >>>> let's say that the UAC receives a final success response, >> say a 200 >>>> response, with a modified To header field from a party that is >>>> blacklisted by UAC policy. What exactly is the UAC supposed >>>> to do? Send >>>> a 403? One cannot reject responses. Maybe a CANCEL? As >> section 9.1 of >>>> RFC3261 says, CANCEL "has no effect on requests that have already >>>> generated a final response." Drop the request on the floor? >>>> You'll just >>>> receive retransmissions. All you can do is ACK it, since the >>>> dialog has >>>> already been formed, and then send a BYE. In other words, >> a session >>>> -will- be established, there simply isn't an opportunity >> for policy to >>>> be put into effect prior to session establishment. Also, >> consider the >>>> need for the new responses defined in the sip-identity >> draft, like say >>>> the 438 response - if the UAC receives a 200 response with a >>>> potentially >>>> repairable error in the Identity header, how can it >> express that error >>>> to the UAS, since it can't send responses to a response? >>>> =09 >>>> Given the above, why does the UAC need to know who has been >>>> reached in the response, rather than in a request after >> the dialog has >>>> been formed? As (c) illustrates, in the 200 response case a >>>> session will >>>> be established anyway, so sharing the identity of the >> connected party >>>> after session establishment doesn't actually miss some >> opportunity for >>>> applying policy - moreover, an UPDATE or similar request >> that provides >>>> the connected-identity information could be rejected by the >>>> session-originating UA in a manner that is helpful to the >>>> session-terminating UA (e.g., a 438 response could be >> sent). If we go >>>> with the mechanism in the connected-identity draft, problem (b) >>>> disappears, since request routing is far more malleable >> than response >>>> routing. Additionally, the connected-identity draft >> wisely does not >>>> attempt to solve "unconnected party" problems from (a), >> which are the >>>> least tractable of the unanticipated respondent problems. Rather, >>>> connected-identity provides an indication more along the >>>> lines of, "your >>>> dialog was established, however that might have happened, >> and this is >>>> who is on the other side". >>>> =09 >>>> Furthermore, any solution that tried to put the >>>> connected-identity information into responses would be >> providing an >>>> imprimatur of legitimacy to those responses - presuming they had a >>>> signature, UACs would validate it, and provided it >> checked out, they >>>> would be tempted say "this is a legitimate response." >> Nothing could be >>>> further from the truth, as sipping-retarget illustrates. >> Legitimacy of >>>> responses cannot be determined by UACs in the absence of >>>> something like >>>> request-history. >>>> =09 >>>> Finally, I like having one Identity header, and for the meaning >>>> of that Identity header to *always* be that it is a >> signature over the >>>> =46rom header field issued by the domain identified by the host >>>> portion of >>>> the addr-spec of the =46rom header field. The current >> connected-identity >>>> header draft provides that property. >>>> =09 >>>> Jon Peterson >>>> NeuStar, Inc. >>>> >>>> -----Original Message----- >>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>> Sent: Monday, April 03, 2006 11:46 PM >>>> To: sip@ietf.org >>>> Subject: [Sip] Connected-identity and changing the To >>>> header field in aresponse >>>> =09 >>>> =09 >>>> >>>> During discussion of draft-elwell-connected-identity in >>>> Dallas, somebody put forward the opinion that it would be >> dangerous to >>>> change the To header field URI in a response (i.e., make >> it different >>>> from the =46rom header field URI in the request). My >> assumption at the >>>> time was that it would undermine the transaction concept >> in SIP, yet >>>> reading what RFC3261 has to say about transactions, the value >>>> of the To >>>> header field URI in a response does not appear to be involved in >>>> coupling a response to a request. Therefore I assume the >> person who >>>> indicated the danger (which was not challenged at the >>>> meeting) has other >>>> reasons in mind. I would greatly appreciate opinions on >> the wisdom or >>>> otherwise of allowing the To header field URI to change. >> It seems that >>>> from discussion of connected-identity there is a desire from >>>> some parts >>>> of the community to include an (unauthenticated) identity in >>>> a response. >>>> >>>> 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 >> >> >> _______________________________________________________________ >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=3D021192 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 15 10:04:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdeS-0005e7-Iq; Mon, 15 May 2006 10:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdeR-0005e2-B5 for sip@ietf.org; Mon, 15 May 2006 10:02:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfdeQ-0004pm-1N for sip@ietf.org; Mon, 15 May 2006 10:02:23 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 07:02:21 -0700 X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="276756836:sNHT35071392" 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/8.12.11) with ESMTP id k4FE2LM6025455; Mon, 15 May 2006 07:02:21 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4FE2KJj013110; Mon, 15 May 2006 07:02:20 -0700 (PDT) Received: from [10.43.1.79] ([10.61.64.139]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 07:02:18 -0700 In-Reply-To: <05CD3DD2-EA4B-4055-AF43-7B944342FA35@softarmor.com> References: <1BEEE9EB-701F-4F80-96C6-B9DB169C6D89@softarmor.com> <4460EC2E.6060307@cisco.com> <05CD3DD2-EA4B-4055-AF43-7B944342FA35@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40487398-1560-4529-83AC-9DE368692DEC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Mon, 15 May 2006 16:02:13 +0200 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 15 May 2006 14:02:20.0156 (UTC) FILETIME=[2E8B8BC0:01C67828] DKIM-Signature: a=rsa-sha1; q=dns; l=978; t=1147701741; x=1148565741; c=relaxed/simple; s=sjdkim7001; 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=203rd=20party=20registration=20(was=20RE=3A=20[Sip]=20SIP=20MIB=20 ietf-sip-mib=09comments); X=v=3Dcisco.com=3B=20h=3DGg6PnSmlUPYcvahfSn/LL8VYBXo=3D; b=rfTwdb2NMxyHgoLCBtXoFoWpCIBpVds5MTEE0WfxvUfEcUCZP9BLDmdfFHMeMZhbQoOpyiPC uTq56MgKFHpEE/4CBwaxwZlC+5EZpK0s3vgGRvJXCvdUvHM46AFeZDIJ; 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Juergen Schoenwaelder , SIP IETF , Paul Kyzivat , "Kevin Lingle \(\(klingle\)\)" , "Romascanu, Dan \(\(Dan\)\)" , Jean-Francois Mule X-BeenThere: sip@ietf.org X-Mailman-Version: 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 this point, the value of finishing this MIB far outweighs the value this discussion will add to the MIB. I will happily support whatever the author choose to do to close this issue. Cullen On May 10, 2006, at 5:19 PM, Dean Willis wrote: > > On May 9, 2006, at 2:23 PM, Paul Kyzivat wrote: > >> >> I have heard of at least one implementation that supports 3rd >> party registration. > > But do we have any need to track and report on 3rd party > registrations at the MIB level differently than we do 1st party > registrations? > > Or is a registration just a registration from a peg-count perspective? > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 15 10:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffdgl-0006AG-LS; Mon, 15 May 2006 10:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffdgj-00068A-Q0 for sip@ietf.org; Mon, 15 May 2006 10:04:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffdgh-0004s0-Gn for sip@ietf.org; Mon, 15 May 2006 10:04:45 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2006 07:04:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="28035388:sNHT33535172" 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 k4FE4gTL017235; Mon, 15 May 2006 10:04:42 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 10:04:42 -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: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Date: Mon, 15 May 2006 10:04:41 -0400 Message-ID: <0DEB933345E95A4083C4403CD2E7980C01A8726B@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) Thread-Index: AcZ4KDJRWLjIsar/QGe54ZeGCtsaSQAAD+qQ From: "Kevin Lingle \(klingle\)" To: "Cullen Jennings \(fluffy\)" , "Dean Willis" X-OriginalArrivalTime: 15 May 2006 14:04:42.0139 (UTC) FILETIME=[832C6EB0:01C67828] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: SIP IETF , "Romascanu, Dan \(\(Dan\)\)" , "Paul Kyzivat \(pkyzivat\)" , Juergen Schoenwaelder , Jean-Francois Mule X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org jean-francois,=20 at this point, i'd vote to simply remove the object.=20 kevin -----Original Message----- From: Cullen Jennings (fluffy)=20 Sent: Monday, May 15, 2006 10:02 AM To: Dean Willis Cc: Paul Kyzivat (pkyzivat); SIP IETF; Romascanu, Dan ((Dan)); Jean-Francois Mule; Kevin Lingle (klingle); Juergen Schoenwaelder Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) At this point, the value of finishing this MIB far outweighs the value this discussion will add to the MIB. I will happily support whatever the author choose to do to close this issue. Cullen On May 10, 2006, at 5:19 PM, Dean Willis wrote: > > On May 9, 2006, at 2:23 PM, Paul Kyzivat wrote: > >> >> I have heard of at least one implementation that supports 3rd party=20 >> registration. > > But do we have any need to track and report on 3rd party registrations > at the MIB level differently than we do 1st party registrations? > > Or is a registration just a registration from a peg-count perspective? > > -- > 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 sip-implementors@cs.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 May 15 10:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffdld-0007kq-TQ; Mon, 15 May 2006 10:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffdlc-0007ki-Jm for sip@ietf.org; Mon, 15 May 2006 10:09:48 -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 1Ffdlc-00053Q-IF for sip@ietf.org; Mon, 15 May 2006 10:09:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfdlU-00086Q-HF for sip@ietf.org; Mon, 15 May 2006 10:09:45 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 07:09:39 -0700 X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="276761375:sNHT42820604" 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/8.12.11) with ESMTP id k4FE9diP030418; Mon, 15 May 2006 07:09:39 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4FE9dsF026481; Mon, 15 May 2006 07:09:39 -0700 (PDT) Received: from [10.43.1.79] ([10.61.64.139]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 07:09:39 -0700 In-Reply-To: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Mon, 15 May 2006 16:09:42 +0200 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 15 May 2006 14:09:39.0364 (UTC) FILETIME=[34555E40:01C67829] DKIM-Signature: a=rsa-sha1; q=dns; l=1379; t=1147702179; x=1148566179; c=relaxed/simple; s=sjdkim8001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3DwUQdvhawa4bCU3L5RVZDcy/QkEc=3D; b=dBn1478M4rBVRGJon09rY7sXhK5E+6V9pCwaYVaCJGqnYMGa0G3zmXQBd/EUKF45vZhS64fc 1tggS/UhMdJEGfCCvWTzCFHzw72tOch8prfRZ5ycbOedMeFkFKMzRbgh; Authentication-Results: sj-dkim-8.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 On May 9, 2006, at 8:54 PM, Dean Willis wrote: > > RFC 3969 defines the registry for SIP/SIPS URI parameters. > > It currently says: > > 4.2. Registration Policy for SIP and SIPS URI Parameters > > As per the terminology in RFC 2434 [4], the registration policy for > SIP and SIPS URI parameters shall be "Specification Required". > > For the purposes of this registry, the parameter for which IANA > registration is requested MUST be defined by a standards-track RFC. > > > Note that the above two paragraphs seem to be self contradictory. > "Specification Required" means 3GPP and recognized bodies can > define parameters by publishing specifications. But"Standards Track > RFC" means only IETF can do so, and it has to be done with an IETF- > consensus standards-track document. > > Note that the IANA registry currently says: > > > SIP/SIPS URI Parameters RFC3969 Specification Required > > SIP/SIPS URI Parameters - per [RFC3969] > (New registrations are via Specification Required) > > This means that the current IANA policy for this registry is > "Specification Required". > > > Which did we mean? We might want to check with Allison on history of this but my vague recollection was last time we discussed this, we decided we meant "Standards Track". I forget the details and may be totally wrong. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 15 10:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfeAV-0006ng-P3; Mon, 15 May 2006 10:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfeAU-0006nb-P4 for sip@ietf.org; Mon, 15 May 2006 10:35: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 1FfeAR-0005ry-Qw for sip@ietf.org; Mon, 15 May 2006 10:35:30 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IZB003019U5Y9@siemenscomms.co.uk> for sip@ietf.org; Mon, 15 May 2006 15:34:56 +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 <0IZB002CG9TGU9@siemenscomms.co.uk>; Mon, 15 May 2006 15:34:28 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 15 May 2006 15:34:00 +0100 Content-return: allowed Date: Mon, 15 May 2006 15:33:58 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: Cullen Jennings , Roland Jesske , "Christer Holmberg (JO/LMF)" Message-id: <50B1CBA96870A34799A506B2313F266708EB28C9@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Cc: sip@ietf.org, 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, I guess what I meant in my message below was the following. If for TIP = there is a need to put the identity in a response to the INVITE request, then = that should not be part of the Connected-Identity draft. However, if the = existing mechanism in the Connected-Identity draft is sufficient to solve TIP, = then that is fine by me. John=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 15 May 2006 04:48 > To: Roland Jesske; Christer Holmberg (JO/LMF) > Cc: Elwell, John; Jon Peterson; sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 > Can someone explain to me why it is that the TIP requirement can not = > be solved with the connected-identity draft? I do understand it may =20 > not be the way some people desire to solve this problem but first of = > all I am just trying to understand what parts of the requirements we = > can't meet with this. >=20 > Thanks, Cullen >=20 >=20 > On Apr 5, 2006, at 10:48 PM, Elwell, John wrote: >=20 > > Roland, > > > > Yes, there was indeed a misunderstanding, but my draft was not =20 > > written with > > TISPAN requirements in mind. It was written to solve the problem of > > authenticated identity, or rather to extend the present=20 > concept of the > > Identity header to mid-dialog requests and show how that can be =20 > > used to > > solve certain problems. > > > > The Terminating Identity Presentation (TIP) requirement=20 > from TISPAN =20 > > needs to > > be addressed by some other means. I don't think modifying the To =20 > > header is > > appropriate. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From =20 > > header > > field URIs throughout a dialog (i.e., it anticipates that these =20 > > will be > > allowed to change mid-dialog), it says nothing to warn of any =20 > > future removal > > of the requirement that the To header field URI in the response be = > > the same > > as that in the request. > > > > Therefore it seems that whatever solution you adopt for=20 > solving the =20 > > TISPAN > > TIP problem, it would have little in common with the connected-=20 > > identity > > draft. > > > > John > > > > > >> -----Original Message----- > >> From: Roland Jesske [mailto:roland.jesske@web.de] > >> Sent: 05 April 2006 14:33 > >> To: Christer Holmberg (JO/LMF); Elwell, John; Peterson, Jon; > >> sip@ietf.org > >> Subject: RE: [Sip] Connected-identity and changing the To > >> header field ina response > >> > >> John, > >> there it looks like a misunderstanding. Thought all > >> requirements from IETF and TISPAN can be solved within your draft. > >> > >> As you saw he additional connected identity is a requirement > >> comming from TISPAN and that was discussed in also in > >> Vancover. In draft-sasaki-sipping-tispan-adhoc-summary-00.txt > >> it is mentioned. > >> > >> Terminating Identification Presentation(TIP)- The working group > >> requests that this requirement be better defined and =20 > >> documented. > >> It is also suggested that TISPAN consider reading > >> draft-rosenberg-sip-identity-privacy-00 as it may solve the > >> problem of calling into an 800 number, getting an=20 > operator, and > >> being able to call back that operator and still protect the > >> privacy of the operator. > >> In addition, work is progressing on > >> draft-elwell-sip-connected-identity-00. > >> > >> So using the PAI does not need to go deeper into > >> draft-rosenberg-sip-identity-privacy-00, but looking into=20 > your draft. > >> And looking within your draft using the dialogUriChange > >> element we thought we have the solution if this can be done > >> within the final Response of the initial INVITE. > >> > >> Best Regards > >> > >> Roland > >> > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: "Elwell, John" > >>> Gesendet: 05.04.06 14:56:20 > >>> An: sip@ietf.org > >>> Betreff: RE: [Sip] Connected-identity and changing the To > >> header field ina response > >> > >> > >>> Christer, > >>> > >>> This "additional connected number" is not a requirement > >> that I have been > >>> trying to address. Was this among the requirements that > >> TISPAN brought into > >>> the IETF recently? > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Christer Holmberg (JO/LMF) > >>>> [mailto:christer.holmberg@ericsson.com] > >>>> Sent: 05 April 2006 08:34 > >>>> To: Elwell, John; Peterson, Jon; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To > >>>> header field inaresponse > >>>> > >>>> > >>>> Hi, > >>>> > >>>> In PSTN terms we are talking about that the TO header shall > >>>> be mapped to > >>>> the additional connected number, and that does NOT need to be > >>>> authorized > >>>> in the same way as the connected number. > >>>> > >>>> And, whether the interworking node sends this value to PSTN > >>>> is of course > >>>> based on local policy, based on trust etc. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>> Sent: 5. huhtikuuta 2006 10:01 > >>>> To: Peterson, Jon; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To > >> header field > >>>> inaresponse > >>>> > >>>> > >>>> Jon, > >>>> > >>>> Thanks for this excellent summary of the issue, which I fully > >>>> agree with > >>>> and which unfortunately seems to need restating at regular > >>>> intervals. It > >>>> appears that the chief motivation of those asking for > >> something in the > >>>> response is to facilitate interworking with PSTN (by > >>>> including it in the > >>>> 200 response so that it can be mapped directly to the > >> PSTN "connected" > >>>> message). As you say, such a response is always going to be > >>>> unauthenticated, and I don't think that meets the > >> requirements of PSTN > >>>> interworking. Far better to figure out a way of using an > >> authenticated > >>>> connected identity in an UPDATE message for mapping to > >> PSTN connected > >>>> identity. > >>>> > >>>> Of course, in trusted networks there may be other means for > >>>> ensuring the > >>>> authenticity of an identity in a response, just as there is > >>>> in a request > >>>> using P-Asserted-Identity. Unfortunately RFC3325 is > >> unclear on the use > >>>> of PAI in responses, although in practice I think it is > >> used and is > >>>> probably OK if the last hop is secured by TLS so that previous > >>>> authentication of the UAS can be relied on for making the > >> assertion. I > >>>> think if those trusted networks really need a solution > >> for response > >>>> identity, PAI would be a better avenue to explore (taking > >> into account > >>>> the risks). But not for the Internet. I am becoming more and = more > >>>> convinced that diluting the connected-identity draft with a weak > >>>> solution for response identity would be the wrong way to go. > >>>> > >>>> John > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>>> Sent: 05 April 2006 02:05 > >>>> To: Elwell, John; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To = header > >>>> field in aresponse > >>>> =09 > >>>> =09 > >>>> Yes, I was asked for clarification on this point after the > >>>> meeting, and I'll be providing it here. As you surmised, it > >>>> is not that > >>>> RFC3261 relies on the addr-spec of the To or From header=20 > field for > >>>> transaction identification, or something. In fact, I would have > >>>> essentially the same concerns about any proposal that provided = an > >>>> additional header (say, a 'Connected-Party' header) in > >> responses to > >>>> dialog-forming requests which was understood to clobber > >> the To header > >>>> field and identify the AoR of the party who was reached after > >>>> retargeting of the request took place. > >>>> =09 > >>>> Starting with the goals of this approach: what sort of UAC > >>>> decisions or behavior do we hope to enable through > >> sending a response > >>>> with a modified To header field? As far as I can > >> understand, we either > >>>> want to render this AoR to the user of a UAC (so the user > >> can react in > >>>> one way or another), or input the AoR to some sort of > >> policy manager > >>>> (e.g. blacklist/whitelist) that might make a decision > >> about whether or > >>>> not the session should continue -prior- to session > >>>> establishment. If we > >>>> don't care about this occurring prior to session=20 > establishment, of > >>>> course, then we could go with the connected-identity > >> draft as it is > >>>> written today. > >>>> =09 > >>>> A little refresher on my sipping-retarget draft: The core > >>>> problem with any scheme for connected party is figuring > >> out how you'd > >>>> decide whether or not a particular respondent is authorized. > >>>> This is the > >>>> argument of 2.2.1 of sipping-retarget, the "unanticipated > >> respondent" > >>>> problem. When we think about what sorts of policy decisions > >>>> we expect a > >>>> human or automata to make when receiving a response with = identity > >>>> information, we have to acknowledge that the UAC has no > >> way of knowing > >>>> which respondents are or are not authorized to respond to the > >>>> request in > >>>> question. Since the UAC has no insight into any > >> retargeting that has > >>>> taken place, the UAC has to assume that virtually any > >> response is a > >>>> potentially legitimate one. As such, there is little room for = any > >>>> meaningful policy decision when receiving a response. > >> This problem is > >>>> further compounded by the fact that the UAS may have > >> several possible > >>>> legitimate AoRs it could claim (I have a UA that > >> registers its contact > >>>> address under 3 separate SIP services simultaneously), and of > >>>> course the > >>>> fact that AoRs may be pretty uninformative (e.g. > >>>> sip:user31@freesipservice.example.com), all of which complicate > >>>> authorization decisions. Solving this problem is on the same > >>>> footing as > >>>> solving the request-history problem set. > >>>> =09 > >>>> With that background, the problems with providing this = connected > >>>> party information in responses (via the To header or what > >>>> have you) are > >>>> roughly as follows: > >>>> =09 > >>>> a) The "unanticipated respondent" problem is especially an = issue > >>>> for response identity because not all responses are > >> success responses. > >>>> If you end up connecting to a party (receiving a 200), you can > >>>> potentially rely on human factors to help you identify=20 > who you are > >>>> talking to (after all, Carol can always answer Bob's phone > >>>> regardless of > >>>> who SIP thinks you connected to) and/or use the connected party > >>>> information to change how you might address the party on the > >>>> other side. > >>>> With a 403 response, you are in a very different > >> predicament - how is > >>>> UAC or user behavior supposed to change based on the=20 > connected URI > >>>> attributed to a 403, given the unanticipated respondent > >> problem? For > >>>> provisional responses, the issues become even worse - we > >> then get into > >>>> the wonders of forking, multiple provisional responses > >> from multiple > >>>> sources asserting different To header fields - in short, > >> nothing which > >>>> makes it any easier to render a "responding" AoR to a user, > >>>> for example. > >>>> Response identity, in so far as it deals with non-final, > >>>> non-successful > >>>> responses, opens up the "unconnected party" problem set. I > >>>> think this is > >>>> just the wrong framing of the problem. You want to know who you > >>>> connected to, not who you didn't connect to. > >>>> =09 > >>>> b) Getting a signature over the To header field in responses > >>>> would be difficult. In full awareness of Mr. Elwell's > >> note below that > >>>> certain parties are interested in "(unauthenticated)=20 > identity in a > >>>> response", if this information is going to be put to any > >>>> purpose, cause > >>>> any change in human or UAC behavior, I have a hard time=20 > seeing how > >>>> anyone could defend it being unsecured. If you want a human or = an > >>>> automata to make a policy decision based on the AoR in > >> the To header > >>>> field of the response, some sort of response identity > >>>> signature would be > >>>> necessary to prevent obvious impersonation attacks > >> designed to thwart > >>>> authorization decisions. With all due respect to the authors of > >>>> draft-cao-sip-response-identity/auth, I'm not sure this=20 > problem is > >>>> readily solved. Making sure that an appropriate > >> authentication service > >>>> is in the path of responses is problematic, since responses must > >>>> traverse exactly the same path as requests. I played around > >>>> with this a > >>>> lot in the early phases of SIP identity, and at the end > >> of the day, I > >>>> had to conclude that the only way to make this work was > >> to eliminate > >>>> retargeting. Since providing connected-identity in > >> responses assumes > >>>> that retargeting has taken place, it wouldn't exactly be > >>>> getting off on > >>>> the right foot. Constraining inbound request routing to a > >> domain such > >>>> that responses will traverse an authentication service, or > >>>> forcing a UAS > >>>> to participate in the Identity scheme, is likely to > >> require mandatory > >>>> option-tags or comparable mechanisms that will limit the > >> applicability > >>>> of response identity and more or less eliminate its > >> opportunistic use. > >>>> =09 > >>>> c) The inability to reject a response. Take the easiest case - > >>>> let's say that the UAC receives a final success response, > >> say a 200 > >>>> response, with a modified To header field from a party that is > >>>> blacklisted by UAC policy. What exactly is the UAC supposed > >>>> to do? Send > >>>> a 403? One cannot reject responses. Maybe a CANCEL? As > >> section 9.1 of > >>>> RFC3261 says, CANCEL "has no effect on requests that have = already > >>>> generated a final response." Drop the request on the floor? > >>>> You'll just > >>>> receive retransmissions. All you can do is ACK it, since the > >>>> dialog has > >>>> already been formed, and then send a BYE. In other words, > >> a session > >>>> -will- be established, there simply isn't an opportunity > >> for policy to > >>>> be put into effect prior to session establishment. Also, > >> consider the > >>>> need for the new responses defined in the sip-identity > >> draft, like say > >>>> the 438 response - if the UAC receives a 200 response with a > >>>> potentially > >>>> repairable error in the Identity header, how can it > >> express that error > >>>> to the UAS, since it can't send responses to a response? > >>>> =09 > >>>> Given the above, why does the UAC need to know who has been > >>>> reached in the response, rather than in a request after > >> the dialog has > >>>> been formed? As (c) illustrates, in the 200 response case a > >>>> session will > >>>> be established anyway, so sharing the identity of the > >> connected party > >>>> after session establishment doesn't actually miss some > >> opportunity for > >>>> applying policy - moreover, an UPDATE or similar request > >> that provides > >>>> the connected-identity information could be rejected by the > >>>> session-originating UA in a manner that is helpful to the > >>>> session-terminating UA (e.g., a 438 response could be > >> sent). If we go > >>>> with the mechanism in the connected-identity draft, problem (b) > >>>> disappears, since request routing is far more malleable > >> than response > >>>> routing. Additionally, the connected-identity draft > >> wisely does not > >>>> attempt to solve "unconnected party" problems from (a), > >> which are the > >>>> least tractable of the unanticipated respondent problems. = Rather, > >>>> connected-identity provides an indication more along the > >>>> lines of, "your > >>>> dialog was established, however that might have happened, > >> and this is > >>>> who is on the other side". > >>>> =09 > >>>> Furthermore, any solution that tried to put the > >>>> connected-identity information into responses would be > >> providing an > >>>> imprimatur of legitimacy to those responses - presuming=20 > they had a > >>>> signature, UACs would validate it, and provided it > >> checked out, they > >>>> would be tempted say "this is a legitimate response." > >> Nothing could be > >>>> further from the truth, as sipping-retarget illustrates. > >> Legitimacy of > >>>> responses cannot be determined by UACs in the absence of > >>>> something like > >>>> request-history. > >>>> =09 > >>>> Finally, I like having one Identity header, and for the meaning > >>>> of that Identity header to *always* be that it is a > >> signature over the > >>>> From header field issued by the domain identified by the host > >>>> portion of > >>>> the addr-spec of the From header field. The current > >> connected-identity > >>>> header draft provides that property. > >>>> =09 > >>>> Jon Peterson > >>>> NeuStar, Inc. > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>> Sent: Monday, April 03, 2006 11:46 PM > >>>> To: sip@ietf.org > >>>> Subject: [Sip] Connected-identity and changing the To > >>>> header field in aresponse > >>>> =09 > >>>> =09 > >>>> > >>>> During discussion of draft-elwell-connected-identity in > >>>> Dallas, somebody put forward the opinion that it would be > >> dangerous to > >>>> change the To header field URI in a response (i.e., make > >> it different > >>>> from the From header field URI in the request). My > >> assumption at the > >>>> time was that it would undermine the transaction concept > >> in SIP, yet > >>>> reading what RFC3261 has to say about transactions, the value > >>>> of the To > >>>> header field URI in a response does not appear to be involved in > >>>> coupling a response to a request. Therefore I assume the > >> person who > >>>> indicated the danger (which was not challenged at the > >>>> meeting) has other > >>>> reasons in mind. I would greatly appreciate opinions on > >> the wisdom or > >>>> otherwise of allowing the To header field URI to change. > >> It seems that > >>>> from discussion of connected-identity there is a desire from > >>>> some parts > >>>> of the community to include an (unauthenticated) identity in > >>>> a response. > >>>> > >>>> 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=20 > application of sip > >> > >> > >> _______________________________________________________________ > >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=3D021192 > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 May 15 11:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffelf-0000ME-NX; Mon, 15 May 2006 11:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffeld-0000Gq-Qz for sip@ietf.org; Mon, 15 May 2006 11:13:53 -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 1Ffelb-0007FI-IC for sip@ietf.org; Mon, 15 May 2006 11:13:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 15 May 2006 08:13:50 -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/8.12.11) with ESMTP id k4FFDp42018239; Mon, 15 May 2006 08:13:51 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4FFDosF028919; Mon, 15 May 2006 08:13:50 -0700 (PDT) Received: from [10.43.1.79] ([10.61.64.139]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 08:13:50 -0700 In-Reply-To: <50B1CBA96870A34799A506B2313F266708EB28C9@ntht201e.siemenscomms.co.uk> References: <50B1CBA96870A34799A506B2313F266708EB28C9@ntht201e.siemenscomms.co.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E65718D-216B-4EFE-A93A-7130A53AADB6@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Connected-identity and changing the To header field ina response Date: Mon, 15 May 2006 17:13:53 +0200 To: "Elwell, John" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 15 May 2006 15:13:50.0710 (UTC) FILETIME=[2BEA2160:01C67832] DKIM-Signature: a=rsa-sha1; q=dns; l=279; t=1147706031; x=1148570031; c=relaxed/simple; s=sjdkim5001; 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]=20Connected-identity=20and=20changing=20the=20To=20header= 20field=20ina=20response; X=v=3Dcisco.com=3B=20h=3Df84KHgZGNz0QggvC4EBI34LfHus=3D; b=gwyZWWd0i4z/8x8GeOJg1+sVhLNoNuIDzuqcKP82zQPheN35sYHshMxBvWluaXisLEtwbGK4 04sYf8aQce0gnaEfII5ZyACxrVwnl+wwiqxTW2wNCk/E2JGXdk+drR+u; 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sip@ietf.org, Jon Peterson , Roland Jesske , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 15, 2006, at 4:33 PM, Elwell, John wrote: > . If for TIP there > is a need to put the identity in a response to the INVITE request, > then that > should not be part of the Connected-Identity draft. I would view that as a possible solution not a requirement. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 15 11:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fff4L-0005uz-OP; Mon, 15 May 2006 11:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fff4K-0005qw-2M for sip@ietf.org; Mon, 15 May 2006 11:33:12 -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 1Fff4J-0000Cu-Ps for sip@ietf.org; Mon, 15 May 2006 11:33:12 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IZB00J01CK116@siemenscomms.co.uk> for sip@ietf.org; Mon, 15 May 2006 16:33:38 +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 <0IZB00I06CIXUX@siemenscomms.co.uk>; Mon, 15 May 2006 16:32:57 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Mon, 15 May 2006 16:32:29 +0100 Content-return: allowed Date: Mon, 15 May 2006 16:32:27 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: Cullen Jennings Message-id: <50B1CBA96870A34799A506B2313F266708EB29F2@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, Jon Peterson , Roland Jesske , "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 Cullen, Quite so. Therefore the question to others is: what is the TIP requirement that cannot be met by the current Connected-Identity solution? John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 15 May 2006 16:14 > To: Elwell, John > Cc: Roland Jesske; Christer Holmberg (JO/LMF); Jon Peterson; > sip@ietf.org > Subject: Re: [Sip] Connected-identity and changing the To > header field ina response > > > On May 15, 2006, at 4:33 PM, Elwell, John wrote: > > > . If for TIP there > > is a need to put the identity in a response to the INVITE request, > > then that > > should not be part of the Connected-Identity draft. > > I would view that as a possible solution not a requirement. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 15 11:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FffQ0-0002jo-K7; Mon, 15 May 2006 11:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FffPz-0002jj-MB for sip@ietf.org; Mon, 15 May 2006 11:55:35 -0400 Received: from web31801.mail.mud.yahoo.com ([68.142.207.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FffPy-0003TN-DM for sip@ietf.org; Mon, 15 May 2006 11:55:35 -0400 Received: (qmail 15274 invoked by uid 60001); 15 May 2006 15:55:33 -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=nSyp63q3ONk12kgGaMAZEYbKUlLPccJwfJoZO8aBxHQHRGmf8yers3zYw2iy5MqNu4vPTrq0Yb6wMdFs/TAGHhIfpqia4f7+U86+lJ9d2wlfZdpJ+QX0BRHSc98bSuyLAH7D0MW59Y60I8K9fjYSlgBlA6U+3nPzy4v0LVx0aHk= ; Message-ID: <20060515155533.15270.qmail@web31801.mail.mud.yahoo.com> Received: from [85.15.17.4] by web31801.mail.mud.yahoo.com via HTTP; Mon, 15 May 2006 08:55:33 PDT Date: Mon, 15 May 2006 08:55:33 -0700 (PDT) From: Behrad Zari To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] REFER and Refer-To header X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, I want to know the standard way to put customized headers into a triggered INVITE of a REFER message (if any)? I'm looking for something like: Refer-To: ;myHeader="myValue" in my REFER message that can be [somehow] put in the generated INVITE. --Behrad __________________________________________________ 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 Mon May 15 12:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fffoi-0004tj-Ty; Mon, 15 May 2006 12:21:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fffoh-0004ta-Cl for sip@ietf.org; Mon, 15 May 2006 12:21:07 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fffod-0004mh-5h for sip@ietf.org; Mon, 15 May 2006 12:21:07 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id C62896C017 for ; Mon, 15 May 2006 12:20:55 -0400 (EDT) Subject: Re: [Sip] REFER and Refer-To header From: "Dale R. Worley" To: Sip In-Reply-To: <20060515155533.15270.qmail@web31801.mail.mud.yahoo.com> References: <20060515155533.15270.qmail@web31801.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 15 May 2006 12:20:55 -0400 Message-Id: <1147710055.19246.23.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Mon, 2006-05-15 at 08:55 -0700, Behrad Zari wrote: > Hi All, > I want to know the standard way to put customized > headers into a triggered INVITE of a REFER message (if > any)? Use a header-parameter in the Refer-To URI: REFER target@... SIP/2.0 Refer-To: Then the INVITE will look like: INVITE sip:behrad@cc.basamd.acc myHeader: myValue See section 19.1.1, which describes how header-parameters are to be processed. 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 May 15 16:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffk4c-0002mU-Bh; Mon, 15 May 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 1Ffk4a-0002mP-Pq for sip@ietf.org; Mon, 15 May 2006 16:53:48 -0400 Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffk4Y-00041y-Fa for sip@ietf.org; Mon, 15 May 2006 16:53:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 May 2006 16:55:58 -0400 Message-ID: <395FBEF8576A0743B44A7C362541CBB3725027@rvnj-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4028 (Session Timer) related question Thread-Index: AcZ4Yfd33og2cO/JQR+e9EwX/wthyA== From: "Sergey Markovich" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Subject: [Sip] RFC 4028 (Session Timer) related question X-BeenThere: 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="===============0617628396==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0617628396== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67861.EBB4B60E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67861.EBB4B60E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have the following scenario: =20 1. A has Session Timer mechanism enabled. 2. A calls B, the call is established 3. A is sending reINVITEs with "Session-Expires" header to B periodically. B is replying with OK without "Session-Expires" or "Supported:timer", i.e. B does not support the Session Timer mechanism, A is a refresher. 4. B puts A on hold, i.e. it sends SDP related reINVITE without "Session-Expires" or "Supported:timer" 5. A replies with OK without "Session-Expires" and it stops (disables) the mechanism, i.e. no session timer related callbacks anymore, the application does not do refresh (does not send reINVITEs) anymore. =20 I am not sure that step 5 is RFC 4028 compliant. I know that the default value of "Session-Expires" is infinity, but I think it makes sense only when the sending party (B) DOES support the mechanism (i.e. does include "Supported:timer", but does not include "Session-Expires" in the reINVITE). In that case the reINVITE can be used for the negotiation of the mechanism parameters. But in our case the reINVITE from step 4 has to be treated as "refresh" only (because after step 4 A knows that B is alive). So A has to restart the timer but not to disable the mechanism. =20 It would be appreciated if you comment what should we do in step 5.=20 =20 Thanks a lot, =20 Sergey =20 ------_=_NextPart_001_01C67861.EBB4B60E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have the following scenario:

 

1.       = A  has Session Timer mechanism enabled.

2.       = A calls B,  the call = is established

3.       = A is sending reINVITEs with “Session-Expires” header to B periodically. B = is replying  with OK without “Session-Expires” or “Supported:timer”, i.e. B does not support the Session Timer mechanism, A is a refresher.

4.       = B puts A on hold, i.e. it sends SDP related reINVITE without = “Session-Expires” or “Supported:timer”

5.       = A  replies with OK without “Session-Expires” and it stops (disables) the mechanism, i.e. no session timer related callbacks = anymore, the application does not do refresh (does not send reINVITEs) = anymore.

 

I am not sure that step 5 is RFC 4028 = compliant.

I know that the default value of “Session-Expires” is infinity, but I think it makes sense = only when the sending party (B) DOES support the mechanism (i.e. does include “Supported:timer”, but does not include “Session-Expires” in the reINVITE). In that case the = reINVITE can be used for the negotiation of the mechanism parameters. But in our case = the reINVITE from step 4 has to be treated as “refresh” only = (because after step 4 A knows that B is alive). So A has to restart the timer but = not to disable the mechanism.

 

It would be appreciated if you comment what should we = do in step 5.

 

Thanks a lot,

 

Sergey

 

------_=_NextPart_001_01C67861.EBB4B60E-- --===============0617628396== 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 --===============0617628396==-- From sip-bounces@ietf.org Mon May 15 17:48:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfktI-0000hc-L1; Mon, 15 May 2006 17:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfktG-0000ff-HJ for sip@ietf.org; Mon, 15 May 2006 17:46:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfktG-0006xu-4L for sip@ietf.org; Mon, 15 May 2006 17:46:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 14:46:10 -0700 X-IronPort-AV: i="4.05,130,1146466800"; d="scan'208"; a="277113909:sNHT1290903168" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4FLk9nO015143; Mon, 15 May 2006 14:46:09 -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 k4FLk5Bl023745; Mon, 15 May 2006 14:46:09 -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.211); Mon, 15 May 2006 14:46:09 -0700 Received: from [10.21.96.250] ([10.21.96.250]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:46:08 -0700 Message-ID: <4468F6A0.4090208@cisco.com> Date: Mon, 15 May 2006 17:46:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sergey Markovich Subject: Re: [Sip] RFC 4028 (Session Timer) related question References: <395FBEF8576A0743B44A7C362541CBB3725027@rvnj-mail1.RADVISION.com> In-Reply-To: <395FBEF8576A0743B44A7C362541CBB3725027@rvnj-mail1.RADVISION.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 May 2006 21:46:08.0606 (UTC) FILETIME=[F99807E0:01C67868] DKIM-Signature: a=rsa-sha1; q=dns; l=2416; t=1147729569; x=1148593569; c=relaxed/simple; s=sjdkim4001; 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]=20RFC=204028=20(Session=20Timer)=20related=20question; X=v=3Dcisco.com=3B=20h=3DQ4lpy7KHbQ/EjyR+Vuh90i2Xfws=3D; b=KgbLhlEjxcdExOu7fPz632SDCgnkkb67ODNGw9d4FfJBaQz6V0/AF/8qpedeDgXz4ZL6GSP1 B7Bq2zSU1rZUlxbcYxZMHRi2IciXshAsGQAmWNzv/bLmCyErkKzhKa59; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Sergey, For this scenario to make sense there should be a proxy involved that is interested in having a session timer. If there was, then it would insert a Session-Expires into reinvite of step 4, and A would respond, reestablishing the timer. If there is no proxy doing this, then there is no need for a session timer to be established. If A wants to periodically check the status of the session, it may do so an any time by sending a reinvite. Paul Sergey Markovich wrote: > We have the following scenario: > > > > 1. A has Session Timer mechanism enabled. > > 2. A calls B, the call is established > > 3. A is sending reINVITEs with “Session-Expires” header to B > periodically. B is replying with OK without “Session-Expires” or > “Supported:timer”, i.e. B does not support the Session Timer mechanism, > A is a refresher. > > 4. B puts A on hold, i.e. it sends SDP related reINVITE without > “Session-Expires” or “Supported:timer” > > 5. A replies with OK without “Session-Expires” and it stops > (disables) the mechanism, i.e. no session timer related callbacks > anymore, the application does not do refresh (does not send reINVITEs) > anymore. > > > > I am not sure that step 5 is RFC 4028 compliant. > > I know that the default value of “Session-Expires” is infinity, but I > think it makes sense only when the sending party (B) DOES support the > mechanism (i.e. does include “Supported:timer”, but does not include > “Session-Expires” in the reINVITE). In that case the reINVITE can be > used for the negotiation of the mechanism parameters. But in our case > the reINVITE from step 4 has to be treated as “refresh” only (because > after step 4 A knows that B is alive). So A has to restart the timer but > not to disable the mechanism. > > > > It would be appreciated if you comment what should we do in step 5. > > > > Thanks a lot, > > > > Sergey > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 15 19:27:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmQK-0000nW-Od; Mon, 15 May 2006 19:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmQI-0000nR-Lh for sip@ietf.org; Mon, 15 May 2006 19:24:22 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfmQH-0002Lx-Ck for sip@ietf.org; Mon, 15 May 2006 19:24:22 -0400 Received: from dimension.cornfed.com (pool-70-16-26-40.balt.east.verizon.net [70.16.26.40]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4FNOIO07259 for ; Mon, 15 May 2006 18:24:18 -0500 From: "Frank W. Miller" To: sip@ietf.org Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Mon, 15 May 2006 19:19:45 -0400 Message-Id: <1147735185.2507.1.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Update to PING draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've updated the PING draft: draft-fwmiller-ping-03 http://www.cornfed.com/ping.txt http://www.cornfed.com/ping.html There was one paragraph that I overlooked that still referred to no retransmissions that has been removed. The draft definitely calls out a standard NIT with standard retransmissions. I'm also uploading the .txt version to the IETF side tonight. Thanks, 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 Mon May 15 23:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfqfP-0006Fq-4V; Mon, 15 May 2006 23:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfqfM-0006Fa-Dy for sip@ietf.org; Mon, 15 May 2006 23:56:12 -0400 Received: from [219.141.250.3] (helo=mail.cecwireless.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfqfK-00059X-EU for sip@ietf.org; Mon, 15 May 2006 23:56:12 -0400 Received: from asechenshuping (ase_chenshuping.cecwireless.com.cn [10.2.4.52]) by mail.cecwireless.com.cn (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTPA id <0IZC00JFYAVMI5@mail.cecwireless.com.cn> for sip@ietf.org; Tue, 16 May 2006 11:55:01 +0800 (CST) Date: Tue, 16 May 2006 11:55:43 +0800 From: Chen Shuping Subject: =?gb2312?B?tPC4tDogW1NpcF0gUkZDIDQwMjggKFNlc3Npb24gVGltZXIpIHJlbA==?= =?gb2312?B?YXRlZCBxdWVzdGlvbg==?= In-reply-to: <395FBEF8576A0743B44A7C362541CBB3725027@rvnj-mail1.RADVISION.com> To: 'Sergey Markovich' , sip@ietf.org Message-id: <006401c6789c$9af11540$326f10ac@cecwireless.com.cn> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcZ4Yfd33og2cO/JQR+e9EwX/wthyAAOkigg X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 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="===============1844400163==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1844400163== Content-type: multipart/alternative; boundary="Boundary_(ID_PIm3+Ypv/6Hfu7Mcfuw+7Q)" This is a multi-part message in MIME format. --Boundary_(ID_PIm3+Ypv/6Hfu7Mcfuw+7Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable I met this problem also. I think the spirit of RFC4028 is to keep session alive by signal = exchange, So, when i received re-Invite(on hold request) from B,firstly, sipua = accept hold request, =20 secondly,sipua in A restart refresh-timer. =20 I am not sure it is the right process.=20 _____ =20 =B7=A2=BC=FE=C8=CB: Sergey Markovich [mailto:SMarkovich@radvision.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA5=D4=C216=C8=D5 4:56 =CA=D5=BC=FE=C8=CB: sip@ietf.org =D6=F7=CC=E2: [Sip] RFC 4028 (Session Timer) related question We have the following scenario: =20 1. A has Session Timer mechanism enabled. 2. A calls B, the call is established 3. A is sending reINVITEs with =A1=B0Session-Expires=A1=B1 header = to B periodically. B is replying with OK without =A1=B0Session-Expires=A1=B1 = or =A1=B0Supported:timer=A1=B1, i.e. B does not support the Session Timer = mechanism, A is a refresher. 4. B puts A on hold, i.e. it sends SDP related reINVITE without =A1=B0Session-Expires=A1=B1 or =A1=B0Supported:timer=A1=B1 5. A replies with OK without =A1=B0Session-Expires=A1=B1 and it = stops (disables) the mechanism, i.e. no session timer related callbacks = anymore, the application does not do refresh (does not send reINVITEs) anymore. =20 I am not sure that step 5 is RFC 4028 compliant. I know that the default value of =A1=B0Session-Expires=A1=B1 is = infinity, but I think it makes sense only when the sending party (B) DOES support the mechanism (i.e. does include =A1=B0Supported:timer=A1=B1, but does not = include =A1=B0Session-Expires=A1=B1 in the reINVITE). In that case the reINVITE = can be used for the negotiation of the mechanism parameters. But in our case the reINVITE from step 4 has to be treated as =A1=B0refresh=A1=B1 only = (because after step 4 A knows that B is alive). So A has to restart the timer but not = to disable the mechanism. =20 It would be appreciated if you comment what should we do in step 5.=20 =20 Thanks a lot, =20 Sergey =20 --Boundary_(ID_PIm3+Ypv/6Hfu7Mcfuw+7Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
I met this problem also.
I think the spirit of RFC4028 is to keep = session alive by=20 signal exchange,
So, when i received re-Invite(on hold request) = from=20 B,firstly, sipua accept hold request,
 
secondly,sipua in A  restart=20 refresh-timer.
 
I am not sure it is the right=20 process. 

=B7=A2=BC=FE=C8=CB: Sergey = Markovich=20 [mailto:SMarkovich@radvision.com]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2006=C4=EA5=D4=C216=C8=D5=20 4:56
=CA=D5=BC=FE=C8=CB: sip@ietf.org
=D6=F7=CC=E2: = [Sip] RFC 4028 (Session Timer)=20 related question

We have the following = scenario:

 

1.       = A  has=20 Session Timer mechanism enabled.

2.       = A calls=20 B, =  the call is=20 established

3.       = A is sending=20 reINVITEs with =A1=B0Session-Expires=A1=B1 header to B periodically. B = is replying=20  with OK without =A1=B0Session-Expires=A1=B1 or = =A1=B0Supported:timer=A1=B1, i.e. B does not=20 support the Session Timer mechanism, A is a=20 refresher.

4.       = B puts A on=20 hold, i.e. it sends SDP related reINVITE without = =A1=B0Session-Expires=A1=B1 or=20 =A1=B0Supported:timer=A1=B1

5.       = A=20  replies with OK without =A1=B0Session-Expires=A1=B1 and it stops = (disables) the=20 mechanism, i.e. no session timer related callbacks anymore, the = application does=20 not do refresh (does not send reINVITEs) = anymore.

 

I am not sure that step 5 = is RFC=20 4028 compliant.

I know that the default = value of=20 =A1=B0Session-Expires=A1=B1 is infinity, but I think it makes sense only = when the sending=20 party (B) DOES support the mechanism (i.e. does include = =A1=B0Supported:timer=A1=B1, but=20 does not include =A1=B0Session-Expires=A1=B1 in the reINVITE). In that = case the reINVITE=20 can be used for the negotiation of the mechanism parameters. But in our = case the=20 reINVITE from step 4 has to be treated as =A1=B0refresh=A1=B1 only = (because after step 4 A=20 knows that B is alive). So A has to restart the timer but not to disable = the=20 mechanism.

 

It would be appreciated if = you=20 comment what should we do in step 5.

 

Thanks a=20 lot,

 

Sergey

 

--Boundary_(ID_PIm3+Ypv/6Hfu7Mcfuw+7Q)-- --===============1844400163== 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 --===============1844400163==-- From sip-bounces@ietf.org Tue May 16 01:49:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfsO8-0000XU-Nl; Tue, 16 May 2006 01:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfsO7-0000XP-FS for sip@ietf.org; Tue, 16 May 2006 01:46:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfsO5-0000PW-4a for sip@ietf.org; Tue, 16 May 2006 01:46:31 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 15 May 2006 22:46:29 -0700 X-IronPort-AV: i="4.05,131,1146466800"; d="scan'208"; a="277358201:sNHT35389772" 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/8.12.11) with ESMTP id k4G5kSKg018651; Mon, 15 May 2006 22:46:28 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4G5kSsF004763; Mon, 15 May 2006 22:46:28 -0700 (PDT) Received: from [10.43.1.79] ([10.21.154.83]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 22:46:28 -0700 In-Reply-To: <1147735185.2507.1.camel@dimension.cornfed.com> References: <1147735185.2507.1.camel@dimension.cornfed.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Update to PING draft Date: Tue, 16 May 2006 07:46:32 +0200 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 16 May 2006 05:46:28.0261 (UTC) FILETIME=[13726550:01C678AC] DKIM-Signature: a=rsa-sha1; q=dns; l=858; t=1147758388; x=1148622388; c=relaxed/simple; s=sjdkim6001; 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]=20Update=20to=20PING=20draft; X=v=3Dcisco.com=3B=20h=3DVmk4x4SJOy44yOSnLmSLPyW46AU=3D; b=d2cluIA3aPADRaEfSvW/hRSZde+pIW1Iad3Jl1BADIWJ/asFPWZm3y6oqE2EWrpui6tC4PbO GIOaVOk/XtVybNeEpt3rti0fzuSuKZ2R+OSO9DMI32BlYHDqtWd+Yirm; 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: 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 Why is this any better than using OPTIONs? On May 16, 2006, at 1:19 AM, Frank W. Miller wrote: > > I've updated the PING draft: > > draft-fwmiller-ping-03 > > http://www.cornfed.com/ping.txt > http://www.cornfed.com/ping.html > > There was one paragraph that I overlooked that still referred to no > retransmissions that has been removed. The draft definitely calls > out a > standard NIT with standard retransmissions. > > I'm also uploading the .txt version to the IETF side tonight. > > Thanks, > FM > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 16 02:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffsel-0005Fx-8J; Tue, 16 May 2006 02:03:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffsej-0005Fq-PS for sip@ietf.org; Tue, 16 May 2006 02:03:41 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffsej-000145-G2 for sip@ietf.org; Tue, 16 May 2006 02:03:41 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 02:03:41 -0400 X-IronPort-AV: i="4.05,132,1146456000"; d="scan'208"; a="88641281:sNHT30437060" 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 k4G63fvF003919 for ; Tue, 16 May 2006 02:03:41 -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.211); Tue, 16 May 2006 02:03:41 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:03:40 -0400 Message-ID: <446955E0.70506@cisco.com> Date: Tue, 16 May 2006 00:32:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:03:40.0987 (UTC) FILETIME=[7AFFE0B0:01C678AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Sip] comments on draft-ietf-sip-fork-loop-fix-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 My big comment on this document is, per Robert's most recent note, he is suggesting that we clarify the usage of loop detection in this document also. He has also suggested proposing an alternative algorithm for this. I think we need to see that text ASAP so we can conclude this; This is an important document and I hope it doesn't take as long as so many of our other ones. Comments on the current draft: > Addressing an Amplification Vulnerability in Forking Proxies > draft-ietf-sip-fork-loop-fix-01 The title should mention SIP somewhere. And spell it out of course. > a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 > /\ /\ /\ /\ /\ /\ /\ /\ > . > . > . > > Figure 2 Figure 2 needs a label and a reference from the text. > The attack can be simplified to one account at one server if the > service can be convinced that contacts with varying attributes > (parameters, schemes, embedded headers) are sufficiently distinct, > and these parameters are not used as part of AOR comparisons when > forwarding a new request. Perhaps: > > REGISTER sip:P1 SIP/2.0 > To: > Contact: , I don't think it takes any work to convince the service. RFC 3261 says that all URI params MUST be removed before looking up in the location service. Furthermore, contacts are compared using full URI equality. Thus, in a properly implemented proxy the single-account approach will always work. You should clarify that. > When a SIP proxy forks a particular request to more than one > destination, it MUST ensure that request is not looping through this > proxy. "this" could refer to the destination or to itself. Suggest: "..looping through itself." > A > proxy is not required to perform loop detection when forwarding a > request to a single location even if it previously forked that > request in its progression through the network. Not required to perform it on that particular forwarding operation. It still needed to do it previously when it forked. > These requirements and the recommendation to use the loop-detection > mechanisms from RFC 3261 make the favorable trade of exponential > message growth for work that is at worst case order n^2 as a message > crosses n proxies. Specifically, this work is order m*n where m is > the number of proxies in the path that fork the request to more than > one location. In practice, m is expected to be small. You should explain what this work is - checking each of the N via headers. You also don't explicitly say that this n^2 work is spread across n proxies. Its only N at any particular proxy. This is important because, as I argued at the mike, I think the constant in front of this is sufficiently small to be unimportant. 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 May 16 02:39:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftAy-0005tT-H4; Tue, 16 May 2006 02:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftAw-0005tF-OY for sip@ietf.org; Tue, 16 May 2006 02:36:58 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FftAv-0002S2-Cd for sip@ietf.org; Tue, 16 May 2006 02:36:58 -0400 Received: (qmail 27081 invoked by uid 0); 16 May 2006 06:36:47 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 May 2006 06:36:47 -0000 Message-ID: <001001c678b3$16c4e780$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "IETF SIP List" References: <446955E0.70506@cisco.com> Subject: Re: [Sip] comments on draft-ietf-sip-fork-loop-fix-01 Date: Tue, 16 May 2006 08:36:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >> These requirements and the recommendation to use the loop-detection >> mechanisms from RFC 3261 make the favorable trade of exponential >> message growth for work that is at worst case order n^2 as a message >> crosses n proxies. Specifically, this work is order m*n where m is >> the number of proxies in the path that fork the request to more than >> one location. In practice, m is expected to be small. > > You should explain what this work is - checking each of the N via headers. > You also don't explicitly say that this n^2 work is spread across n > proxies. Its only N at any particular proxy. This is important because, > as I argued at the mike, I think the constant in front of this is > sufficiently small to be unimportant. > I would expect that the bulk of the work is not inspecting the Via headers, but rather calculating the digest for distinguishing loops from spirals. And you're trading *potential* (typically very rare) exponential message growth for *guaranteed* (always, for every forked request) order n^2 work. So on average, the trade-off might not be "favorable" 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 May 16 02:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftMK-0000gJ-Ih; Tue, 16 May 2006 02:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftMJ-0000gE-FJ for sip@ietf.org; Tue, 16 May 2006 02:48:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FftMI-00039z-6h for sip@ietf.org; Tue, 16 May 2006 02:48:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2006 23:48:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,132,1146466800"; d="scan'208"; a="28103386:sNHT22575408" 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 k4G6mfTL015708; Tue, 16 May 2006 02:48:41 -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.211); Tue, 16 May 2006 02:48:41 -0400 Received: from [192.168.128.160] ([10.82.225.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 02:48:40 -0400 Message-ID: <446975C7.3080006@cisco.com> Date: Tue, 16 May 2006 02:48:39 -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] comments on draft-ietf-sip-fork-loop-fix-01 References: <446955E0.70506@cisco.com> <001001c678b3$16c4e780$31713b51@BEMBUSTER> In-Reply-To: <001001c678b3$16c4e780$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 06:48:40.0893 (UTC) FILETIME=[C444D6D0:01C678B4] 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Jeroen van Bemmel wrote: >>> These requirements and the recommendation to use the loop-detection >>> mechanisms from RFC 3261 make the favorable trade of exponential >>> message growth for work that is at worst case order n^2 as a message >>> crosses n proxies. Specifically, this work is order m*n where m is >>> the number of proxies in the path that fork the request to more than >>> one location. In practice, m is expected to be small. >> >> >> You should explain what this work is - checking each of the N via >> headers. You also don't explicitly say that this n^2 work is spread >> across n proxies. Its only N at any particular proxy. This is >> important because, as I argued at the mike, I think the constant in >> front of this is sufficiently small to be unimportant. >> > > I would expect that the bulk of the work is not inspecting the Via > headers, but rather calculating the digest for distinguishing loops from > spirals. Sure. But you only need to do that when there is a loop of any sort. In other words, you first check to see if your address is on the Via list. Only if its there do you bother to check if it was a loop vs. a spiral. > And you're trading *potential* (typically very rare) > exponential message growth for *guaranteed* (always, for every forked > request) order n^2 work. Well, the huge potential damage from this attack really does require this tradeoff. I still don't think the work is that significant. Its O(N) on each proxy and I really do think this constant is very small. Just the time it takes to find your own address in the Via list. -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 May 16 05:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfvXg-0005ck-Kj; Tue, 16 May 2006 05:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfvXf-0005cf-PT for sip@ietf.org; Tue, 16 May 2006 05:08:36 -0400 Received: from [203.187.132.2] (helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfvXS-0001oP-6e for sip@ietf.org; Tue, 16 May 2006 05:08:35 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.11.6) with ESMTP id k4G96phf012378; Tue, 16 May 2006 14:37:00 +0530 In-Reply-To: To: Cullen Jennings Subject: Re: [Sip] Update to PING draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Vikram Agarwal Date: Tue, 16 May 2006 14:36:49 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/16/2006 02:37:05 PM, Serialize complete at 05/16/2006 02:37:05 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: sip@ietf.org, fwmiller@cornfed.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: , Content-Type: multipart/mixed; boundary="===============1807701728==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1807701728== Content-Type: multipart/alternative; boundary="=_alternative 0032104665257170_=" This is a multipart message in MIME format. --=_alternative 0032104665257170_= Content-Type: text/plain; charset="US-ASCII" Hi Cullen, The same point i had raised some time back when the PING method was being introduced (w.r.t NAT keep alive). The response from Jonathan R. i got was that PING would be a modified SIP method, where only some 2 - 3 headers would be parsed (not like OPTIONS method where all the mandatory headers would be parsed) to save the parsing time. But, now when i see the PING draft, it is the same like OPTIONS. i.e nothing new w.r.t parsing of headers in the PING/OPTIONS method. In this case i am not able to get the significance of introducing the PING method over OPTIONS? Please refer to the response below from Jonathan: "I will further note that a "modified PING message", or any other kind of SIP message processing that does not follow SIP semantics as defined in RFC 3261, is effectively identical to the multiple-protocol mechanism of running STUN and SIP on the same port. You'll need to figure out which protocol it is (SIP or modified SIP), and send the request to the right code path appropirately." Regards, --Vikram. Cullen Jennings 05/16/2006 11:16 AM To fwmiller@cornfed.com cc sip@ietf.org Subject Re: [Sip] Update to PING draft Why is this any better than using OPTIONs? On May 16, 2006, at 1:19 AM, Frank W. Miller wrote: > > I've updated the PING draf > > draft-fwmiller-ping-03 > > http://www.cornfed.com/ping.txt > http://www.cornfed.com/ping.html > > There was one paragraph that I overlooked that still referred to no > retransmissions that has been removed. The draft definitely calls > out a > standard NIT with standard retransmissions. > > I'm also uploading the .txt version to the IETF side tonight. > > Thanks, > FM > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0032104665257170_= Content-Type: text/html; charset="US-ASCII"
Hi Cullen,

  The same point i had raised some time back when the PING method was being introduced (w.r.t NAT keep alive). The response from Jonathan R. i got was that PING would be a modified SIP method, where only some 2 - 3 headers would be parsed (not like OPTIONS method where all the mandatory headers would be parsed) to save the parsing time. But, now when i see the PING draft, it is the same like OPTIONS. i.e nothing new w.r.t parsing of headers in the PING/OPTIONS method. In this case i am not able to get the significance of introducing the PING method over OPTIONS?

Please refer to the response below from Jonathan:

"I will further note that a "modified PING message", or any other kind of
SIP message processing that does not follow SIP semantics as defined in
RFC 3261, is effectively identical to the multiple-protocol mechanism of
running STUN and SIP on the same port. You'll need to figure out which
protocol it is (SIP or modified SIP), and send the request to the right
code path appropirately."

Regards,
--Vikram.
 


Cullen Jennings <fluffy@cisco.com>

05/16/2006 11:16 AM

To
fwmiller@cornfed.com
cc
sip@ietf.org
Subject
Re: [Sip] Update to PING draft






Why is this any better than using OPTIONs?


On May 16, 2006, at 1:19 AM, Frank W. Miller wrote:

>
> I've updated the PING draf
>
> draft-fwmiller-ping-03
>
> http://www.cornfed.com/ping.txt
> http://www.cornfed.com/ping.html
>
> There was one paragraph that I overlooked that still referred to no
> retransmissions that has been removed.  The draft definitely calls  
> out a
> standard NIT with standard retransmissions.
>
> I'm also uploading the .txt version to the IETF side tonight.
>
> Thanks,
> FM
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 0032104665257170_=-- --===============1807701728== 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 --===============1807701728==-- From sip-bounces@ietf.org Tue May 16 07:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxfb-0005Qd-Q2; Tue, 16 May 2006 07:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxfb-0005N4-18 for sip@ietf.org; Tue, 16 May 2006 07:24:55 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfxfZ-0008Gd-P1 for sip@ietf.org; Tue, 16 May 2006 07:24:54 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4GBOpQj019102 for ; Tue, 16 May 2006 04:24:51 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4GBOnSl007057 for ; Tue, 16 May 2006 06:24:50 -0500 (CDT) Received: from motorola.com ([10.232.117.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 19:24:49 +0800 Message-ID: <4469B6B0.4010307@motorola.com> Date: Tue, 16 May 2006 16:55:36 +0530 From: Preeti agarwal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org References: <000801c635ff$6262c2d0$b2b04c0a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 11:24:49.0327 (UTC) FILETIME=[57D33BF0:01C678DB] X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] SIP Presence testing X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Please let me know if there is any tool available to test PoC PRESENCE, Or some sample test cases which I can download and run on my server. As SIPp tool. Thanks, Priti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 16 08:26:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyZ3-0004Sf-CM; Tue, 16 May 2006 08:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyZ2-0004Sa-3A for sip@ietf.org; Tue, 16 May 2006 08:22:12 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyZ0-0003V5-Bw for sip@ietf.org; Tue, 16 May 2006 08:22:12 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4GCLr0P018592; Tue, 16 May 2006 07:21:53 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 May 2006 13:21:53 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012F29935@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Cullen Jennings , Roland Jesske , "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Connected-identity and changing the To header field ina response Date: Tue, 16 May 2006 13:21:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id k4GCLr0P018592 X-Spam-Score: 0.5 (/) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 Cc: sip@ietf.org, John Elwell , 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 As far as I understand the requirment, the issue is the need to be able t= o transport two identities for connected, with different assertions. If P-Asserted-Identity is used for one of them, and this is possible as t= he TISPAN people are looking at an NGN based on trust domain, then this i= s the assertion by the edge of the trust domain, i.e. the edge of the pub= lic network, as to who the user is. However in a number of more complex interconnection scenarios, particular= ly involving enterprise networks, and in imitation of the ISDN, that numb= er may not be sufficient to dial back to the user (it may end up on an at= tendent console in the enterprise network instead). Therefore the enterpr= ise network needs to be able to assert a number as well as to who it beli= eves the end user is. That is the second number that is being talked abou= t by TISPAN. In the ISDN the level of confidence in this number will vary from country= to country. Some countries, e.g. USA, allow anybody to use it. Others re= strict it to specific enterprise networks only. As to whether the connected-identity draft is the right way to solve this= , well in my view that depends on the identity solution that enterprise n= etworks end up using. I have seen some input favouring the use the sip-id= entity solution in enterprise networks rather than P-Asserted-Identity. T= herefore it may well be reasonable that the number delivered by identity = mechanisms can represent the second number needed by TISPAN, in addition = to the first number provided by the P-Asserted-Identity. I would note that I remember talking about this need for multiple numbers= in Las Vegas (SIP ad-hoc), and was told that P-Asserted-Identity would b= e kept simple and any more complex requirements would be met by the sip-i= dentity draft.=20 regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 15 May 2006 04:48 > To: Roland Jesske; Christer Holmberg (JO/LMF) > Cc: sip@ietf.org; John Elwell; Jon Peterson > Subject: Re: [Sip] Connected-identity and changing the To header field > ina response >=20 >=20 >=20 > Can someone explain to me why it is that the TIP requirement can not =20 > be solved with the connected-identity draft? I do understand it may =20 > not be the way some people desire to solve this problem but first of =20 > all I am just trying to understand what parts of the requirements we =20 > can't meet with this. >=20 > Thanks, Cullen >=20 >=20 > On Apr 5, 2006, at 10:48 PM, Elwell, John wrote: >=20 > > Roland, > > > > Yes, there was indeed a misunderstanding, but my draft was not =20 > > written with > > TISPAN requirements in mind. It was written to solve the problem of > > authenticated identity, or rather to extend the present=20 > concept of the > > Identity header to mid-dialog requests and show how that can be =20 > > used to > > solve certain problems. > > > > The Terminating Identity Presentation (TIP) requirement=20 > from TISPAN =20 > > needs to > > be addressed by some other means. I don't think modifying the To =20 > > header is > > appropriate. Whereas RFC 3261 anticipates deprecating fixed=20 > To/From =20 > > header > > field URIs throughout a dialog (i.e., it anticipates that these =20 > > will be > > allowed to change mid-dialog), it says nothing to warn of any =20 > > future removal > > of the requirement that the To header field URI in the response be =20 > > the same > > as that in the request. > > > > Therefore it seems that whatever solution you adopt for=20 > solving the =20 > > TISPAN > > TIP problem, it would have little in common with the connected-=20 > > identity > > draft. > > > > John > > > > > >> -----Original Message----- > >> From: Roland Jesske [mailto:roland.jesske@web.de] > >> Sent: 05 April 2006 14:33 > >> To: Christer Holmberg (JO/LMF); Elwell, John; Peterson, Jon; > >> sip@ietf.org > >> Subject: RE: [Sip] Connected-identity and changing the To > >> header field ina response > >> > >> John, > >> there it looks like a misunderstanding. Thought all > >> requirements from IETF and TISPAN can be solved within your draft. > >> > >> As you saw he additional connected identity is a requirement > >> comming from TISPAN and that was discussed in also in > >> Vancover. In draft-sasaki-sipping-tispan-adhoc-summary-00.txt > >> it is mentioned. > >> > >> Terminating Identification Presentation(TIP)- The working group > >> requests that this requirement be better defined and =20 > >> documented. > >> It is also suggested that TISPAN consider reading > >> draft-rosenberg-sip-identity-privacy-00 as it may solve the > >> problem of calling into an 800 number, getting an=20 > operator, and > >> being able to call back that operator and still protect the > >> privacy of the operator. > >> In addition, work is progressing on > >> draft-elwell-sip-connected-identity-00. > >> > >> So using the PAI does not need to go deeper into > >> draft-rosenberg-sip-identity-privacy-00, but looking into=20 > your draft. > >> And looking within your draft using the dialogUriChange > >> element we thought we have the solution if this can be done > >> within the final Response of the initial INVITE. > >> > >> Best Regards > >> > >> Roland > >> > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: "Elwell, John" > >>> Gesendet: 05.04.06 14:56:20 > >>> An: sip@ietf.org > >>> Betreff: RE: [Sip] Connected-identity and changing the To > >> header field ina response > >> > >> > >>> Christer, > >>> > >>> This "additional connected number" is not a requirement > >> that I have been > >>> trying to address. Was this among the requirements that > >> TISPAN brought into > >>> the IETF recently? > >>> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: Christer Holmberg (JO/LMF) > >>>> [mailto:christer.holmberg@ericsson.com] > >>>> Sent: 05 April 2006 08:34 > >>>> To: Elwell, John; Peterson, Jon; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To > >>>> header field inaresponse > >>>> > >>>> > >>>> Hi, > >>>> > >>>> In PSTN terms we are talking about that the TO header shall > >>>> be mapped to > >>>> the additional connected number, and that does NOT need to be > >>>> authorized > >>>> in the same way as the connected number. > >>>> > >>>> And, whether the interworking node sends this value to PSTN > >>>> is of course > >>>> based on local policy, based on trust etc. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>> Sent: 5. huhtikuuta 2006 10:01 > >>>> To: Peterson, Jon; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To > >> header field > >>>> inaresponse > >>>> > >>>> > >>>> Jon, > >>>> > >>>> Thanks for this excellent summary of the issue, which I fully > >>>> agree with > >>>> and which unfortunately seems to need restating at regular > >>>> intervals. It > >>>> appears that the chief motivation of those asking for > >> something in the > >>>> response is to facilitate interworking with PSTN (by > >>>> including it in the > >>>> 200 response so that it can be mapped directly to the > >> PSTN "connected" > >>>> message). As you say, such a response is always going to be > >>>> unauthenticated, and I don't think that meets the > >> requirements of PSTN > >>>> interworking. Far better to figure out a way of using an > >> authenticated > >>>> connected identity in an UPDATE message for mapping to > >> PSTN connected > >>>> identity. > >>>> > >>>> Of course, in trusted networks there may be other means for > >>>> ensuring the > >>>> authenticity of an identity in a response, just as there is > >>>> in a request > >>>> using P-Asserted-Identity. Unfortunately RFC3325 is > >> unclear on the use > >>>> of PAI in responses, although in practice I think it is > >> used and is > >>>> probably OK if the last hop is secured by TLS so that previous > >>>> authentication of the UAS can be relied on for making the > >> assertion. I > >>>> think if those trusted networks really need a solution > >> for response > >>>> identity, PAI would be a better avenue to explore (taking > >> into account > >>>> the risks). But not for the Internet. I am becoming more and more > >>>> convinced that diluting the connected-identity draft with a weak > >>>> solution for response identity would be the wrong way to go. > >>>> > >>>> John > >>>> > >>>> > >>>> ________________________________ > >>>> > >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > >>>> Sent: 05 April 2006 02:05 > >>>> To: Elwell, John; sip@ietf.org > >>>> Subject: RE: [Sip] Connected-identity and changing the To header > >>>> field in aresponse > >>>> =09 > >>>> =09 > >>>> Yes, I was asked for clarification on this point after the > >>>> meeting, and I'll be providing it here. As you surmised, it > >>>> is not that > >>>> RFC3261 relies on the addr-spec of the To or From header=20 > field for > >>>> transaction identification, or something. In fact, I would have > >>>> essentially the same concerns about any proposal that provided an > >>>> additional header (say, a 'Connected-Party' header) in > >> responses to > >>>> dialog-forming requests which was understood to clobber > >> the To header > >>>> field and identify the AoR of the party who was reached after > >>>> retargeting of the request took place. > >>>> =09 > >>>> Starting with the goals of this approach: what sort of UAC > >>>> decisions or behavior do we hope to enable through > >> sending a response > >>>> with a modified To header field? As far as I can > >> understand, we either > >>>> want to render this AoR to the user of a UAC (so the user > >> can react in > >>>> one way or another), or input the AoR to some sort of > >> policy manager > >>>> (e.g. blacklist/whitelist) that might make a decision > >> about whether or > >>>> not the session should continue -prior- to session > >>>> establishment. If we > >>>> don't care about this occurring prior to session=20 > establishment, of > >>>> course, then we could go with the connected-identity > >> draft as it is > >>>> written today. > >>>> =09 > >>>> A little refresher on my sipping-retarget draft: The core > >>>> problem with any scheme for connected party is figuring > >> out how you'd > >>>> decide whether or not a particular respondent is authorized. > >>>> This is the > >>>> argument of 2.2.1 of sipping-retarget, the "unanticipated > >> respondent" > >>>> problem. When we think about what sorts of policy decisions > >>>> we expect a > >>>> human or automata to make when receiving a response with identity > >>>> information, we have to acknowledge that the UAC has no > >> way of knowing > >>>> which respondents are or are not authorized to respond to the > >>>> request in > >>>> question. Since the UAC has no insight into any > >> retargeting that has > >>>> taken place, the UAC has to assume that virtually any > >> response is a > >>>> potentially legitimate one. As such, there is little room for any > >>>> meaningful policy decision when receiving a response. > >> This problem is > >>>> further compounded by the fact that the UAS may have > >> several possible > >>>> legitimate AoRs it could claim (I have a UA that > >> registers its contact > >>>> address under 3 separate SIP services simultaneously), and of > >>>> course the > >>>> fact that AoRs may be pretty uninformative (e.g. > >>>> sip:user31@freesipservice.example.com), all of which complicate > >>>> authorization decisions. Solving this problem is on the same > >>>> footing as > >>>> solving the request-history problem set. > >>>> =09 > >>>> With that background, the problems with providing this connected > >>>> party information in responses (via the To header or what > >>>> have you) are > >>>> roughly as follows: > >>>> =09 > >>>> a) The "unanticipated respondent" problem is especially an issue > >>>> for response identity because not all responses are > >> success responses. > >>>> If you end up connecting to a party (receiving a 200), you can > >>>> potentially rely on human factors to help you identify=20 > who you are > >>>> talking to (after all, Carol can always answer Bob's phone > >>>> regardless of > >>>> who SIP thinks you connected to) and/or use the connected party > >>>> information to change how you might address the party on the > >>>> other side. > >>>> With a 403 response, you are in a very different > >> predicament - how is > >>>> UAC or user behavior supposed to change based on the=20 > connected URI > >>>> attributed to a 403, given the unanticipated respondent > >> problem? For > >>>> provisional responses, the issues become even worse - we > >> then get into > >>>> the wonders of forking, multiple provisional responses > >> from multiple > >>>> sources asserting different To header fields - in short, > >> nothing which > >>>> makes it any easier to render a "responding" AoR to a user, > >>>> for example. > >>>> Response identity, in so far as it deals with non-final, > >>>> non-successful > >>>> responses, opens up the "unconnected party" problem set. I > >>>> think this is > >>>> just the wrong framing of the problem. You want to know who you > >>>> connected to, not who you didn't connect to. > >>>> =09 > >>>> b) Getting a signature over the To header field in responses > >>>> would be difficult. In full awareness of Mr. Elwell's > >> note below that > >>>> certain parties are interested in "(unauthenticated)=20 > identity in a > >>>> response", if this information is going to be put to any > >>>> purpose, cause > >>>> any change in human or UAC behavior, I have a hard time=20 > seeing how > >>>> anyone could defend it being unsecured. If you want a human or an > >>>> automata to make a policy decision based on the AoR in > >> the To header > >>>> field of the response, some sort of response identity > >>>> signature would be > >>>> necessary to prevent obvious impersonation attacks > >> designed to thwart > >>>> authorization decisions. With all due respect to the authors of > >>>> draft-cao-sip-response-identity/auth, I'm not sure this=20 > problem is > >>>> readily solved. Making sure that an appropriate > >> authentication service > >>>> is in the path of responses is problematic, since responses must > >>>> traverse exactly the same path as requests. I played around > >>>> with this a > >>>> lot in the early phases of SIP identity, and at the end > >> of the day, I > >>>> had to conclude that the only way to make this work was > >> to eliminate > >>>> retargeting. Since providing connected-identity in > >> responses assumes > >>>> that retargeting has taken place, it wouldn't exactly be > >>>> getting off on > >>>> the right foot. Constraining inbound request routing to a > >> domain such > >>>> that responses will traverse an authentication service, or > >>>> forcing a UAS > >>>> to participate in the Identity scheme, is likely to > >> require mandatory > >>>> option-tags or comparable mechanisms that will limit the > >> applicability > >>>> of response identity and more or less eliminate its > >> opportunistic use. > >>>> =09 > >>>> c) The inability to reject a response. Take the easiest case - > >>>> let's say that the UAC receives a final success response, > >> say a 200 > >>>> response, with a modified To header field from a party that is > >>>> blacklisted by UAC policy. What exactly is the UAC supposed > >>>> to do? Send > >>>> a 403? One cannot reject responses. Maybe a CANCEL? As > >> section 9.1 of > >>>> RFC3261 says, CANCEL "has no effect on requests that have already > >>>> generated a final response." Drop the request on the floor? > >>>> You'll just > >>>> receive retransmissions. All you can do is ACK it, since the > >>>> dialog has > >>>> already been formed, and then send a BYE. In other words, > >> a session > >>>> -will- be established, there simply isn't an opportunity > >> for policy to > >>>> be put into effect prior to session establishment. Also, > >> consider the > >>>> need for the new responses defined in the sip-identity > >> draft, like say > >>>> the 438 response - if the UAC receives a 200 response with a > >>>> potentially > >>>> repairable error in the Identity header, how can it > >> express that error > >>>> to the UAS, since it can't send responses to a response? > >>>> =09 > >>>> Given the above, why does the UAC need to know who has been > >>>> reached in the response, rather than in a request after > >> the dialog has > >>>> been formed? As (c) illustrates, in the 200 response case a > >>>> session will > >>>> be established anyway, so sharing the identity of the > >> connected party > >>>> after session establishment doesn't actually miss some > >> opportunity for > >>>> applying policy - moreover, an UPDATE or similar request > >> that provides > >>>> the connected-identity information could be rejected by the > >>>> session-originating UA in a manner that is helpful to the > >>>> session-terminating UA (e.g., a 438 response could be > >> sent). If we go > >>>> with the mechanism in the connected-identity draft, problem (b) > >>>> disappears, since request routing is far more malleable > >> than response > >>>> routing. Additionally, the connected-identity draft > >> wisely does not > >>>> attempt to solve "unconnected party" problems from (a), > >> which are the > >>>> least tractable of the unanticipated respondent problems. Rather, > >>>> connected-identity provides an indication more along the > >>>> lines of, "your > >>>> dialog was established, however that might have happened, > >> and this is > >>>> who is on the other side". > >>>> =09 > >>>> Furthermore, any solution that tried to put the > >>>> connected-identity information into responses would be > >> providing an > >>>> imprimatur of legitimacy to those responses - presuming=20 > they had a > >>>> signature, UACs would validate it, and provided it > >> checked out, they > >>>> would be tempted say "this is a legitimate response." > >> Nothing could be > >>>> further from the truth, as sipping-retarget illustrates. > >> Legitimacy of > >>>> responses cannot be determined by UACs in the absence of > >>>> something like > >>>> request-history. > >>>> =09 > >>>> Finally, I like having one Identity header, and for the meaning > >>>> of that Identity header to *always* be that it is a > >> signature over the > >>>> From header field issued by the domain identified by the host > >>>> portion of > >>>> the addr-spec of the From header field. The current > >> connected-identity > >>>> header draft provides that property. > >>>> =09 > >>>> Jon Peterson > >>>> NeuStar, Inc. > >>>> > >>>> -----Original Message----- > >>>> From: Elwell, John [mailto:john.elwell@siemens.com] > >>>> Sent: Monday, April 03, 2006 11:46 PM > >>>> To: sip@ietf.org > >>>> Subject: [Sip] Connected-identity and changing the To > >>>> header field in aresponse > >>>> =09 > >>>> =09 > >>>> > >>>> During discussion of draft-elwell-connected-identity in > >>>> Dallas, somebody put forward the opinion that it would be > >> dangerous to > >>>> change the To header field URI in a response (i.e., make > >> it different > >>>> from the From header field URI in the request). My > >> assumption at the > >>>> time was that it would undermine the transaction concept > >> in SIP, yet > >>>> reading what RFC3261 has to say about transactions, the value > >>>> of the To > >>>> header field URI in a response does not appear to be involved in > >>>> coupling a response to a request. Therefore I assume the > >> person who > >>>> indicated the danger (which was not challenged at the > >>>> meeting) has other > >>>> reasons in mind. I would greatly appreciate opinions on > >> the wisdom or > >>>> otherwise of allowing the To header field URI to change. > >> It seems that > >>>> from discussion of connected-identity there is a desire from > >>>> some parts > >>>> of the community to include an (unauthenticated) identity in > >>>> a response. > >>>> > >>>> 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=20 > application of sip > >> > >> > >> _______________________________________________________________ > >> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > >> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=3D021192 > >> > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 16 08:57:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffz4g-00045u-72; Tue, 16 May 2006 08:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffz4e-00045p-SI for sip@ietf.org; Tue, 16 May 2006 08:54:52 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffz4c-0004vJ-Ht for sip@ietf.org; Tue, 16 May 2006 08:54:52 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4GCslx01895; Tue, 16 May 2006 07:54:47 -0500 Date: Tue, 16 May 2006 07:54:47 -0500 Message-Id: <200605161254.k4GCslx01895@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Cullen Jennings" , fwmiller@cornfed.com Subject: Re: [Sip] Update to PING draft X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Its not much better than OPTIONS in all likelihood. There is a potential implementation optimization that is frowned upon by some that can make it a little quicker to turnaround but its probably not a huge difference and also may not matter in most cases at the UA that is doing the turnaround. The only reason I updated it is because I have had some private emails that some people are experimenting with it and since there was the error in the text, that should be fixed. FM Frank W. Miller, Ph.D. Cornfed Systems, LLC. www.cornfed.com 410-404-8790 ------------------------------------------------ On Tue, 16 May 2006 07:46:32 +0200, Cullen Jennings wrote: > > Why is this any better than using OPTIONs? > > > On May 16, 2006, at 1:19 AM, Frank W. Miller wrote: > > > > > I've updated the PING draft: > > > > draft-fwmiller-ping-03 > > > > http://www.cornfed.com/ping.txt > > http://www.cornfed.com/ping.html > > > > There was one paragraph that I overlooked that still referred to no > > retransmissions that has been removed. The draft definitely calls > > out a > > standard NIT with standard retransmissions. > > > > I'm also uploading the .txt version to the IETF side tonight. > > > > Thanks, > > FM > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 16 09:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzWl-0003cz-4V; Tue, 16 May 2006 09:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzWj-0003ck-Ss for sip@ietf.org; Tue, 16 May 2006 09:23:53 -0400 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzWj-0006EF-Kp for sip@ietf.org; Tue, 16 May 2006 09:23:53 -0400 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 09:23:53 -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: 3rd party registration (was RE: [Sip] SIP MIBietf-sip-mib comments) Date: Tue, 16 May 2006 09:23:51 -0400 Message-ID: <8812D8156467224C9E9739E513037EF18FD50C@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIP MIBietf-sip-mib comments) Thread-Index: AcZ4KDJRWLjIsar/QGe54ZeGCtsaSQAAD+qQADDWwqA= From: "Bob Natale" To: "SIP IETF" X-OriginalArrivalTime: 16 May 2006 13:23:53.0376 (UTC) FILETIME=[FA029A00:01C678EB] X-Spam-Score: 0.0 (/) 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 I'd like to second Kevin's vote, as well as Cullen's position regardless. Cheers, BobN -----Original Message----- From: Kevin Lingle (klingle) [mailto:klingle@cisco.com]=20 Sent: Monday, May 15, 2006 10:05 AM To: Cullen Jennings (fluffy); Dean Willis Cc: SIP IETF; Romascanu, Dan ((Dan)); Paul Kyzivat (pkyzivat); Juergen Schoenwaelder; Jean-Francois Mule Subject: RE: 3rd party registration (was RE: [Sip] SIP MIBietf-sip-mib comments) jean-francois, at this point, i'd vote to simply remove the object.=20 kevin -----Original Message----- From: Cullen Jennings (fluffy) Sent: Monday, May 15, 2006 10:02 AM To: Dean Willis Cc: Paul Kyzivat (pkyzivat); SIP IETF; Romascanu, Dan ((Dan)); Jean-Francois Mule; Kevin Lingle (klingle); Juergen Schoenwaelder Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments) At this point, the value of finishing this MIB far outweighs the value this discussion will add to the MIB. I will happily support whatever the author choose to do to close this issue. Cullen On May 10, 2006, at 5:19 PM, Dean Willis wrote: > > On May 9, 2006, at 2:23 PM, Paul Kyzivat wrote: > >> >> I have heard of at least one implementation that supports 3rd party=20 >> registration. > > But do we have any need to track and report on 3rd party registrations > at the MIB level differently than we do 1st party registrations? > > Or is a registration just a registration from a peg-count perspective? > > -- > 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 16 10:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0D5-0007sl-9X; Tue, 16 May 2006 10:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0D3-0007sg-TA for sip@ietf.org; Tue, 16 May 2006 10:07:37 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0Cz-0008BY-EJ for sip@ietf.org; Tue, 16 May 2006 10:07:37 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 16 May 2006 16:07:32 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 16 May 2006 16:07:32 +0200 Message-Id: <31529C1D0F94F24989CBC1BCDF3C04970818BE86@S4DE8PSAAGT.blf.telekom.de> From: "Jesske, R" To: john.elwell@siemens.com, fluffy@cisco.com Subject: AW: [Sip] Connected-identity and changing the To header field ina response Date: Tue, 16 May 2006 16:07:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, roland.jesske@web.de, jon.peterson@neustar.biz, christer.holmberg@ericsson.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 John, it is that we don't can get an connected identity within the final = response of the initial INVITE. Your draft proposes a mid dialog request for getting this information. That is not usable for the TIP service. But anyway the usability of the option tag dialogUriChange in section 8 = is described generally. We need the option tag dialogUriChange to change the to header within = Responses. Could there be a way in describing this uri change in responses (let it = generally applicable) and point to your concerns.=20 Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Montag, 15. Mai 2006 17:32 > An: Cullen Jennings > Cc: sip@ietf.org; Jon Peterson; Roland Jesske; Christer=20 > Holmberg (JO/LMF) > Betreff: RE: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 > Cullen, >=20 > Quite so. Therefore the question to others is: what is the=20 > TIP requirement > that cannot be met by the current Connected-Identity solution? >=20 > John >=20 > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > > Sent: 15 May 2006 16:14 > > To: Elwell, John > > Cc: Roland Jesske; Christer Holmberg (JO/LMF); Jon Peterson;=20 > > sip@ietf.org > > Subject: Re: [Sip] Connected-identity and changing the To=20 > > header field ina response > >=20 > >=20 > > On May 15, 2006, at 4:33 PM, Elwell, John wrote: > >=20 > > > . If for TIP there > > > is a need to put the identity in a response to the INVITE=20 > request, =20 > > > then that > > > should not be part of the Connected-Identity draft. > >=20 > > I would view that as a possible solution not a requirement. > >=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 May 16 10:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0GQ-0000b2-Sv; Tue, 16 May 2006 10:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0GP-0000aO-UQ for sip@ietf.org; Tue, 16 May 2006 10:11:05 -0400 Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0GP-0008Is-N1 for sip@ietf.org; Tue, 16 May 2006 10:11:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RFC 4028 (Session Timer) related question Date: Tue, 16 May 2006 10:13:03 -0400 Message-ID: <395FBEF8576A0743B44A7C362541CBB3725041@rvnj-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4028 (Session Timer) related question Thread-Index: AcZ4aUD47LEnH2FfQ9Kn3giMsnM2DwAiLP/w From: "Sergey Markovich" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: sip@ietf.org X-Mailman-Version: 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, A is a proxy in this scenario. Probably I was wrong when I said "A calls B". A just forwards initial INVITE from somebody else to B. B is an endpoint. Sergey -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, May 15, 2006 5:46 PM To: Sergey Markovich Cc: sip@ietf.org Subject: Re: [Sip] RFC 4028 (Session Timer) related question Sergey, For this scenario to make sense there should be a proxy involved that is interested in having a session timer. If there was, then it would insert a Session-Expires into reinvite of step 4, and A would respond,=20 reestablishing the timer. If there is no proxy doing this, then there is no need for a session=20 timer to be established. If A wants to periodically check the status of=20 the session, it may do so an any time by sending a reinvite. Paul Sergey Markovich wrote: > We have the following scenario: >=20 > =20 >=20 > 1. A has Session Timer mechanism enabled. >=20 > 2. A calls B, the call is established >=20 > 3. A is sending reINVITEs with "Session-Expires" header to B=20 > periodically. B is replying with OK without "Session-Expires" or=20 > "Supported:timer", i.e. B does not support the Session Timer mechanism,=20 > A is a refresher. >=20 > 4. B puts A on hold, i.e. it sends SDP related reINVITE without=20 > "Session-Expires" or "Supported:timer" >=20 > 5. A replies with OK without "Session-Expires" and it stops=20 > (disables) the mechanism, i.e. no session timer related callbacks=20 > anymore, the application does not do refresh (does not send reINVITEs) > anymore. >=20 > =20 >=20 > I am not sure that step 5 is RFC 4028 compliant. >=20 > I know that the default value of "Session-Expires" is infinity, but I=20 > think it makes sense only when the sending party (B) DOES support the=20 > mechanism (i.e. does include "Supported:timer", but does not include=20 > "Session-Expires" in the reINVITE). In that case the reINVITE can be=20 > used for the negotiation of the mechanism parameters. But in our case=20 > the reINVITE from step 4 has to be treated as "refresh" only (because=20 > after step 4 A knows that B is alive). So A has to restart the timer but=20 > not to disable the mechanism. >=20 > =20 >=20 > It would be appreciated if you comment what should we do in step 5. >=20 > =20 >=20 > Thanks a lot, >=20 > =20 >=20 > Sergey >=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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 16 12:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2Dl-0002iX-JZ; Tue, 16 May 2006 12:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2Dj-0002cj-NW for sip@ietf.org; Tue, 16 May 2006 12:16:27 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg2Di-00088S-BZ for sip@ietf.org; Tue, 16 May 2006 12:16:27 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 09:16:26 -0700 X-IronPort-AV: i="4.05,134,1146466800"; d="scan'208"; a="1807165864:sNHT178942720" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4GGGPEZ025618; Tue, 16 May 2006 09:16:25 -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 k4GGGKBD010622; Tue, 16 May 2006 09:16:25 -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, 16 May 2006 09:16:23 -0700 Received: from [10.21.90.228] ([10.21.90.228]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 09:16:22 -0700 Message-ID: <4469FAD5.4060003@cisco.com> Date: Tue, 16 May 2006 12:16:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sergey Markovich Subject: Re: [Sip] RFC 4028 (Session Timer) related question References: <395FBEF8576A0743B44A7C362541CBB3725041@rvnj-mail1.RADVISION.com> In-Reply-To: <395FBEF8576A0743B44A7C362541CBB3725041@rvnj-mail1.RADVISION.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 16:16:22.0524 (UTC) FILETIME=[129543C0:01C67904] DKIM-Signature: a=rsa-sha1; q=dns; l=3376; t=1147796185; x=1148660185; c=relaxed/simple; s=sjdkim1001; 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]=20RFC=204028=20(Session=20Timer)=20related=20question; X=v=3Dcisco.com=3B=20h=3D6U2TyJS/L8CBefAFr2aYnfFZ0Gs=3D; b=iKMkOv4ZY7zMf821GaK1Qh/b2LBaFcOfztYOqU4KB812Df+P9AzA7m230sFzyP9ZqOn65Yoo 5Mtim2srZM/v5J3iBbg4cqmXsbRcCIGPZzVlDeW0Jl2Q9xpgt/7xhsKw; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@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 Sergy, Can you restate your problem, showing both UAs and the proxy, and what each does? Paul Sergey Markovich wrote: > Paul, > > A is a proxy in this scenario. Probably I was wrong when I said "A calls > B". A just forwards initial INVITE from somebody else to B. B is an > endpoint. > > Sergey > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, May 15, 2006 5:46 PM > To: Sergey Markovich > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4028 (Session Timer) related question > > Sergey, > > For this scenario to make sense there should be a proxy involved that is > > interested in having a session timer. If there was, then it would insert > > a Session-Expires into reinvite of step 4, and A would respond, > reestablishing the timer. > > If there is no proxy doing this, then there is no need for a session > timer to be established. If A wants to periodically check the status of > the session, it may do so an any time by sending a reinvite. > > Paul > > Sergey Markovich wrote: >> We have the following scenario: >> >> >> >> 1. A has Session Timer mechanism enabled. >> >> 2. A calls B, the call is established >> >> 3. A is sending reINVITEs with "Session-Expires" header to B >> periodically. B is replying with OK without "Session-Expires" or >> "Supported:timer", i.e. B does not support the Session Timer > mechanism, >> A is a refresher. >> >> 4. B puts A on hold, i.e. it sends SDP related reINVITE without >> "Session-Expires" or "Supported:timer" >> >> 5. A replies with OK without "Session-Expires" and it stops >> (disables) the mechanism, i.e. no session timer related callbacks >> anymore, the application does not do refresh (does not send reINVITEs) > >> anymore. >> >> >> >> I am not sure that step 5 is RFC 4028 compliant. >> >> I know that the default value of "Session-Expires" is infinity, but I >> think it makes sense only when the sending party (B) DOES support the >> mechanism (i.e. does include "Supported:timer", but does not include >> "Session-Expires" in the reINVITE). In that case the reINVITE can be >> used for the negotiation of the mechanism parameters. But in our case >> the reINVITE from step 4 has to be treated as "refresh" only (because >> after step 4 A knows that B is alive). So A has to restart the timer > but >> not to disable the mechanism. >> >> >> >> It would be appreciated if you comment what should we do in step 5. >> >> >> >> Thanks a lot, >> >> >> >> Sergey >> >> >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 16 12:26:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2L1-0004yW-SV; Tue, 16 May 2006 12:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg2L0-0004yR-L0 for sip@ietf.org; Tue, 16 May 2006 12:23:58 -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 1Fg2Ky-0008Fu-5y for sip@ietf.org; Tue, 16 May 2006 12:23:58 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IZD00I019KCMA@siemenscomms.co.uk> for sip@ietf.org; Tue, 16 May 2006 17:24:14 +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 <0IZD00H899K5RA@siemenscomms.co.uk>; Tue, 16 May 2006 17:24:05 +0100 (BST) Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Tue, 16 May 2006 17:23:36 +0100 Content-return: allowed Date: Tue, 16 May 2006 17:23:35 +0100 From: "Elwell, John" Subject: RE: [Sip] Connected-identity and changing the To header field ina response To: "Jesske, R" , fluffy@cisco.com Message-id: <50B1CBA96870A34799A506B2313F266708EF895C@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org, roland.jesske@web.de, jon.peterson@neustar.biz, christer.holmberg@ericsson.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 Roland, OK, so I see that this is specified in REQ-TIP-1 in draft-jesske-sipping-tispan-requirements-02. I guess we didn't have a discussion as to why it needs to be in the response. We should either: 1. Amend this requirement to express it in a more general way, rather = than assuming a particular solution. Or 2. Accept that requirement, in which case the connected-identity draft = does not address this TISPAN requirement and some other means of addressing = it will be required. In this case we would need to first agree on a = solution before addressing the question of whether it should be included in the connected-identity draft. John > -----Original Message----- > From: Jesske, R [mailto:R.Jesske@t-com.net]=20 > Sent: 16 May 2006 15:08 > To: Elwell, John; fluffy@cisco.com > Cc: sip@ietf.org; jon.peterson@neustar.biz;=20 > roland.jesske@web.de; christer.holmberg@ericsson.com > Subject: AW: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 > John, > it is that we don't can get an connected identity within the=20 > final response of the initial INVITE. > Your draft proposes a mid dialog request for getting this = information. > That is not usable for the TIP service. >=20 > But anyway the usability of the option tag dialogUriChange in=20 > section 8 is described generally. >=20 > We need the option tag dialogUriChange to change the to=20 > header within Responses. >=20 > Could there be a way in describing this uri change in=20 > responses (let it generally applicable) and point to your concerns.=20 >=20 >=20 > Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Gesendet: Montag, 15. Mai 2006 17:32 > > An: Cullen Jennings > > Cc: sip@ietf.org; Jon Peterson; Roland Jesske; Christer=20 > > Holmberg (JO/LMF) > > Betreff: RE: [Sip] Connected-identity and changing the To=20 > > header field ina response > >=20 > >=20 > > Cullen, > >=20 > > Quite so. Therefore the question to others is: what is the=20 > > TIP requirement > > that cannot be met by the current Connected-Identity solution? > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > > > Sent: 15 May 2006 16:14 > > > To: Elwell, John > > > Cc: Roland Jesske; Christer Holmberg (JO/LMF); Jon Peterson;=20 > > > sip@ietf.org > > > Subject: Re: [Sip] Connected-identity and changing the To=20 > > > header field ina response > > >=20 > > >=20 > > > On May 15, 2006, at 4:33 PM, Elwell, John wrote: > > >=20 > > > > . If for TIP there > > > > is a need to put the identity in a response to the INVITE=20 > > request, =20 > > > > then that > > > > should not be part of the Connected-Identity draft. > > >=20 > > > I would view that as a possible solution not a requirement. > > >=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 >=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 May 16 13:37:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3RK-00010q-5i; Tue, 16 May 2006 13:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3RI-00010l-PV for sip@ietf.org; Tue, 16 May 2006 13:34:32 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3RH-00037M-Cq for sip@ietf.org; Tue, 16 May 2006 13:34:32 -0400 Received: (qmail 24340 invoked by uid 0); 16 May 2006 17:34:27 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 May 2006 17:34:27 -0000 Message-ID: <001201c6790e$f7547c10$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Tue, 16 May 2006 19:34:20 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] draft-ietf-sip-fork-loop-fix-01 : deprecate spiralling for forking proxies X-BeenThere: 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="===============0073450121==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0073450121== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C6791F.BA44B590" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C6791F.BA44B590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Consider the following alternative as a solution to the exponential = message problem: deprecate spiralling for forking proxies "A proxy that forwards a request to more than one destination MUST NOT = forward it to an element (i.e. host/port/transport) which is already in = the via list of that request" This avoids loops caused by forking (even before they materialize), = avoids potential HERFP issues, is easy to implement and more efficient = than digest-based loop detection. Regards, Jeroen ------=_NextPart_000_000F_01C6791F.BA44B590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Consider the following alternative as a = solution to=20 the exponential message problem: deprecate spiralling for forking=20 proxies
 
"A proxy that forwards a request to = more than one=20 destination MUST NOT forward it to an element (i.e. host/port/transport) = which=20 is already in the via list of that request"
 
This avoids loops caused by forking = (even before=20 they materialize), avoids potential HERFP issues, is easy to implement = and more=20 efficient than digest-based loop detection.
 
Regards,
 
Jeroen
------=_NextPart_000_000F_01C6791F.BA44B590-- --===============0073450121== 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 --===============0073450121==-- From sip-bounces@ietf.org Tue May 16 14:32:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4Jh-0000QS-7L; Tue, 16 May 2006 14:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4Jf-0000QN-W0 for sip@ietf.org; Tue, 16 May 2006 14:30:43 -0400 Received: from [216.223.9.5] (helo=rvnj-mail1.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4Jd-0005Or-Az for sip@ietf.org; Tue, 16 May 2006 14:30:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RFC 4028 (Session Timer) related question Date: Tue, 16 May 2006 14:32:49 -0400 Message-ID: <395FBEF8576A0743B44A7C362541CBB3725063@rvnj-mail1.RADVISION.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RFC 4028 (Session Timer) related question Thread-Index: AcZ5BFxMSw716pwuRhya5LznOHzJqAACKW5w From: "Sergey Markovich" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 X-BeenThere: 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="===============1467310773==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1467310773== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67917.19A654A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67917.19A654A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, I checked with our customer. A is a server but it is B2BUA and not a proxy. A is interested to know that B is alive. So there is no proxy. So the scenario is the following: 1. B and C are endpoints. They do not know anything about Session Timer mechanism. 2. A is a B2BUA. It implements Session Timer mechanism.=20 3. C calls A, A calls B, both calls are established. 4. A is sending reINVITEs with "Session-Expires" header to B periodically. B is replying with OK without "Session-Expires" or "Supported:timer", i.e. B does not support the Session Timer mechanism, A is a refresher. 5. Probably the same happens between A and C (on the other leg of B2BUA) 6. B puts A on hold, i.e. it sends SDP related reINVITE without "Session-Expires" or "Supported:timer" 7. A replies with OK without "Session-Expires" and it stops(disables) the mechanism, i.e. no session timer related callbacks anymore, the application does not do refresh (does not send reINVITEs) anymore. Thank you, Sergey -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, May 16, 2006 12:16 PM To: Sergey Markovich Cc: sip@ietf.org Subject: Re: [Sip] RFC 4028 (Session Timer) related question Sergy, Can you restate your problem, showing both UAs and the proxy, and what=20 each does? Paul Sergey Markovich wrote: > Paul, >=20 > A is a proxy in this scenario. Probably I was wrong when I said "A calls > B". A just forwards initial INVITE from somebody else to B. B is an > endpoint. >=20 > Sergey >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, May 15, 2006 5:46 PM > To: Sergey Markovich > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4028 (Session Timer) related question >=20 > Sergey, >=20 > For this scenario to make sense there should be a proxy involved that is >=20 > interested in having a session timer. If there was, then it would insert >=20 > a Session-Expires into reinvite of step 4, and A would respond,=20 > reestablishing the timer. >=20 > If there is no proxy doing this, then there is no need for a session=20 > timer to be established. If A wants to periodically check the status of=20 > the session, it may do so an any time by sending a reinvite. >=20 > Paul >=20 > Sergey Markovich wrote: >> We have the following scenario: >> >> =20 >> >> 1. A has Session Timer mechanism enabled. >> >> 2. A calls B, the call is established >> >> 3. A is sending reINVITEs with "Session-Expires" header to B=20 >> periodically. B is replying with OK without "Session-Expires" or=20 >> "Supported:timer", i.e. B does not support the Session Timer > mechanism,=20 >> A is a refresher. >> >> 4. B puts A on hold, i.e. it sends SDP related reINVITE without >> "Session-Expires" or "Supported:timer" >> >> 5. A replies with OK without "Session-Expires" and it stops=20 >> (disables) the mechanism, i.e. no session timer related callbacks=20 >> anymore, the application does not do refresh (does not send reINVITEs) >=20 >> anymore. >> >> =20 >> >> I am not sure that step 5 is RFC 4028 compliant. >> >> I know that the default value of "Session-Expires" is infinity, but I >> think it makes sense only when the sending party (B) DOES support the >> mechanism (i.e. does include "Supported:timer", but does not include=20 >> "Session-Expires" in the reINVITE). In that case the reINVITE can be=20 >> used for the negotiation of the mechanism parameters. But in our case >> the reINVITE from step 4 has to be treated as "refresh" only (because >> after step 4 A knows that B is alive). So A has to restart the timer > but=20 >> not to disable the mechanism. >> >> =20 >> >> It would be appreciated if you comment what should we do in step 5. >> >> =20 >> >> Thanks a lot, >> >> =20 >> >> Sergey >> >> =20 >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 ------_=_NextPart_001_01C67917.19A654A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Sip] RFC 4028 (Session Timer) related question

Paul,

I = checked with our customer. A is a server but it = is B2BUA and not a proxy.

A is = interested to know that B is alive. So there is no proxy. So the scenario is the following:

1.      = B and C are endpoints. They do not know anything about = Session Timer mechanism.
2.      A is a B2BUA. It implements Session = Timer = mechanism.
3.      C calls A, A calls B, both = calls are established.
4.      = A is sending reINVITEs with = "Session-Expires" header to B periodically. B is = replying  with OK without "Session-Expires" = or "Supported:timer", i.e. B does not support the = Session Timer mechanism, A is a refresher.

5.      Probably the same happens = between A and C (on the other leg of B2BUA)
6.      = B puts A on hold, i.e. it sends SDP = related reINVITE without "Session-Expires" or = "Supported:timer"
7.      = A  replies with OK without = "Session-Expires" and it stops(disables) the mechanism, i.e. no session timer related callbacks = anymore, the application does not do refresh (does not send = reINVITEs) anymore.

Thank you,

Sergey


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, May 16, 2006 12:16 PM
To: Sergey Markovich
Cc: sip@ietf.org
Subject: Re: [Sip] RFC 4028 (Session Timer) related = question

Sergy,

Can you restate your problem, showing both UAs and the proxy, and = what

each does?

        Paul

Sergey Markovich wrote:

> Paul,

>

> A is a proxy in this scenario. Probably I was wrong when I = said "A calls

> B". A just forwards initial INVITE from somebody else to = B. B is an

> endpoint.

>

> Sergey

>

> -----Original Message-----

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] =

> Sent: Monday, May 15, 2006 5:46 PM

> To: Sergey Markovich

> Cc: sip@ietf.org

> Subject: Re: [Sip] RFC 4028 (Session Timer) related = question

>

> Sergey,

>

> For this scenario to make sense there should be a proxy = involved that is

>

> interested in having a session timer. If there was, then it = would insert

>

> a Session-Expires into reinvite of step 4, and A would = respond,

> reestablishing the timer.

>

> If there is no proxy doing this, then there is no need for a = session

> timer to be established. If A wants to periodically check the = status of

> the session, it may do so an any time by sending a = reinvite.

>

>       Paul

>

> Sergey Markovich wrote:

>> We have the following scenario:

>>

>> 

>>

>> 1.       A  has Session = Timer mechanism enabled.

>>

>> 2.       A calls B,  = the call is established

>>

>> 3.       A is sending = reINVITEs with "Session-Expires" header to B =

>> periodically. B is replying  with OK without = "Session-Expires" or

>> "Supported:timer", i.e. B does not support the = Session Timer

> mechanism,

>> A is a refresher.

>>

>> 4.       B puts A on hold, = i.e. it sends SDP related reINVITE without

>> "Session-Expires" or = "Supported:timer"

>>

>> 5.       A  replies = with OK without "Session-Expires" and it stops =

>> (disables) the mechanism, i.e. no session timer related = callbacks

>> anymore, the application does not do refresh (does not = send reINVITEs)

>

>> anymore.

>>

>> 

>>

>> I am not sure that step 5 is RFC 4028 = compliant.

>>

>> I know that the default value of = "Session-Expires" is infinity, but I

>> think it makes sense only when the sending party (B) DOES = support the

>> mechanism (i.e. does include "Supported:timer", = but does not include

>> "Session-Expires" in the reINVITE). In that case = the reINVITE can be

>> used for the negotiation of the mechanism parameters. But = in our case

>> the reINVITE from step 4 has to be treated as = "refresh" only (because

>> after step 4 A knows that B is alive). So A has to restart = the timer

> but

>> not to disable the mechanism.

>>

>> 

>>

>> It would be appreciated if you comment what should we do = in step 5.

>>

>> 

>>

>> Thanks a lot,

>>

>> 

>>

>> Sergey

>>

>> 

>>

>>

>>

> = ------------------------------------------------------------------------<= /FONT>

>> = _______________________________________________

>> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip

>> This list is for NEW development of the core SIP = Protocol

>> Use sip-implementors@cs.columbia.edu for questions on = current sip

>> Use sipping@ietf.org for new developments on the = application of sip

>

>

> = _______________________________________________

> Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip

> This list is for NEW development of the core SIP = 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_01C67917.19A654A0-- --===============1467310773== 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 --===============1467310773==-- From sip-bounces@ietf.org Tue May 16 14:45:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4Ux-0004W1-9I; Tue, 16 May 2006 14:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4Uv-0004Uw-O7 for sip@ietf.org; Tue, 16 May 2006 14:42:21 -0400 Received: from nz-out-0102.google.com ([64.233.162.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4Uu-00061I-V6 for sip@ietf.org; Tue, 16 May 2006 14:42:21 -0400 Received: by nz-out-0102.google.com with SMTP id s18so45527nze for ; Tue, 16 May 2006 11:42: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=knmll2mVLGRJgcXK0Qq1ZUfwwQSvtjzsWRNZNdKwuS/SS1g4wwaZNN1HOebyoyzO7p2bVvzJjK4WSMAHzTtt5118p/jX8x52qrVw9UIx9+Ni2fe7R2waNWfuzikfwi04pcG2rUxYJ9NxYSyRGoWBhMvHtTAwauig+IPz66TNRAs= Received: by 10.36.134.4 with SMTP id h4mr4441133nzd; Tue, 16 May 2006 11:42:20 -0700 (PDT) Received: by 10.36.132.20 with HTTP; Tue, 16 May 2006 11:42:20 -0700 (PDT) Message-ID: <4ff4e7370605161142t67852448p5f729db97f242f0a@mail.gmail.com> Date: Tue, 16 May 2006 11:42:20 -0700 From: Venkatesh To: "Sergey Markovich" Subject: Re: [Sip] RFC 4028 (Session Timer) related question In-Reply-To: <395FBEF8576A0743B44A7C362541CBB3725063@rvnj-mail1.RADVISION.com> MIME-Version: 1.0 References: <395FBEF8576A0743B44A7C362541CBB3725063@rvnj-mail1.RADVISION.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c11d54fae0b5a4f2b2d9ece4929bab8a 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="===============1014346282==" Errors-To: sip-bounces@ietf.org --===============1014346282== Content-Type: multipart/alternative; boundary="----=_Part_10522_6538732.1147804940082" ------=_Part_10522_6538732.1147804940082 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline At step 7, if A wanted to continue using Session-Timers (which seems to be your intent), there is nothing preventing it from adding a Supported: timer and a Session-Expires header with the refresher parameter set to "uas" when sending the 200 OK response for the Hold request. It can then restart its timers. Venkatesh On 5/16/06, Sergey Markovich wrote: > > > Paul, > > I checked with our customer. A is a server but it is B2BUA and not a > proxy. > > A is interested to know that B is alive. So there is no proxy. So the > scenario is the following: > > 1. B and C are endpoints. They do not know anything about Session > Timer mechanism. > 2. A is a B2BUA. It implements Session Timer mechanism. > 3. C calls A, A calls B, both calls are established. > 4. A is sending reINVITEs with "Session-Expires" header to B > periodically. B is replying with OK without "Session-Expires" or "Suppor= ted:timer", > i.e. B does not support the Session Timer mechanism, A is a refresher. > > 5. Probably the same happens between A and C (on the other leg of > B2BUA) > 6. B puts A on hold, i.e. it sends SDP related reINVITE without > "Session-Expires" or "Supported:timer" > 7. A replies with OK without "Session-Expires" and it stops( > disables) the mechanism, i.e. no session timer related callbacks anymore, > the application does not do refresh (does not send reINVITEs) anymore. > > Thank you, > > Sergey > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com ] > Sent: Tuesday, May 16, 2006 12:16 PM > To: Sergey Markovich > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4028 (Session Timer) related question > > Sergy, > > Can you restate your problem, showing both UAs and the proxy, and what > > each does? > > Paul > > Sergey Markovich wrote: > > > Paul, > > > > > > A is a proxy in this scenario. Probably I was wrong when I said "A call= s > > > B". A just forwards initial INVITE from somebody else to B. B is an > > > endpoint. > > > > > > Sergey > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com ] > > > Sent: Monday, May 15, 2006 5:46 PM > > > To: Sergey Markovich > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] RFC 4028 (Session Timer) related question > > > > > > Sergey, > > > > > > For this scenario to make sense there should be a proxy involved that i= s > > > > > > interested in having a session timer. If there was, then it would inser= t > > > > > > a Session-Expires into reinvite of step 4, and A would respond, > > > reestablishing the timer. > > > > > > If there is no proxy doing this, then there is no need for a session > > > timer to be established. If A wants to periodically check the status of > > > the session, it may do so an any time by sending a reinvite. > > > > > > Paul > > > > > > Sergey Markovich wrote: > > >> We have the following scenario: > > >> > > >> > > >> > > >> 1. A has Session Timer mechanism enabled. > > >> > > >> 2. A calls B, the call is established > > >> > > >> 3. A is sending reINVITEs with "Session-Expires" header to B > > >> periodically. B is replying with OK without "Session-Expires" or > > >> "Supported:timer", i.e. B does not support the Session Timer > > > mechanism, > > >> A is a refresher. > > >> > > >> 4. B puts A on hold, i.e. it sends SDP related reINVITE without > > >> "Session-Expires" or "Supported:timer" > > >> > > >> 5. A replies with OK without "Session-Expires" and it stops > > >> (disables) the mechanism, i.e. no session timer related callbacks > > >> anymore, the application does not do refresh (does not send reINVITEs) > > > > > >> anymore. > > >> > > >> > > >> > > >> I am not sure that step 5 is RFC 4028 compliant. > > >> > > >> I know that the default value of "Session-Expires" is infinity, but I > > >> think it makes sense only when the sending party (B) DOES support the > > >> mechanism (i.e. does include "Supported:timer", but does not include > > >> "Session-Expires" in the reINVITE). In that case the reINVITE can be > > >> used for the negotiation of the mechanism parameters. But in our case > > >> the reINVITE from step 4 has to be treated as "refresh" only (because > > >> after step 4 A knows that B is alive). So A has to restart the timer > > > but > > >> not to disable the mechanism. > > >> > > >> > > >> > > >> It would be appreciated if you comment what should we do in step 5. > > >> > > >> > > >> > > >> Thanks a lot, > > >> > > >> > > >> > > >> Sergey > > >> > > >> > > >> > > >> > > >> > > > -----------------------------------------------------------------------= - > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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_10522_6538732.1147804940082 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
At step 7, if A wanted to continue using Session-Timers (which seems t= o be your intent), there is nothing preventing it from adding a Supported: = timer and a Session-Expires header with the refresher parameter set to &quo= t;uas" when sending the 200 OK response for the Hold request. It can t= hen restart its timers.
 
Venkatesh

 
On 5/16/06, = Sergey Markovich <SMarko= vich@radvision.com> wrote:

Paul= ,

I ch= ecked with our customer. A is a server but it is B2BUA and not a proxy.

A is= interested to know that B is alive. <= span lang=3D"en-us"> So there is no proxy. So the scenario is the following:

1.   = ;   B and C are endpoints. They do not know anyt= hing about Session Timer mechanism.
= 2.      A is a B2BUA. It implements Session Timer<= /font> mechanism.<= span lang=3D"en-us"> <= span lang=3D"en-us">
3.      C calls A, A calls B, both calls are est= ablished.
= 4.   &n= bsp;  A is sending reINVITEs with "Session-Expires" header to B periodi= cally. B is replying  with OK without "Session-Expires" or "Supported:timer", i.e. B does not support = the Session Timer mechanism, A is a refresher.

5.   = ;   Probably the same happens between A and C (on the other leg of B2BUA= )
6.      B puts A on hold,=20 i.e. it sends SDP related reINVITE without "Session-Expires" or &= quot;Supported:timer"
7.      A  replies with OK wi= thout "Session-Expires" and it stops (d= isables) the mechanism, i.e. no session timer related callback= s anymore, the application does not do refresh (does not send reINVITEs) anymore.

Thank you,

Sergey


-----Original Message-----
From: Paul Kyzivat [ mailto:pkyzivat@cisco.com]
Sent: Tuesday, May 16, 2006 12:16 PM
T= o: Sergey Markovich
Cc: sip@ietf.org=
Subject: Re: [Sip] RFC 4028 (Session Timer) related question<= span lang=3D"en-us">

Sergy,

Can you restate your problem, showing both UAs and the proxy, and what

each does?

      =   Paul

Sergey Markovich wrote:

> Paul,

>

> A is a proxy in this scenario. Probably I was wrong when I said &quo= t;A calls

> B". A just forwards initial INVITE from somebody else to B. B i= s an

> endpoint.

>

> Sergey

>

> -----Original Message-----

> From: Paul Kyzivat [mailto:pky= zivat@cisco.com ]

> Sent: Monday, May 15, 2006 5:46 PM

> To: Sergey Markovich

> Cc: sip@ietf.org

> Subject: Re: [Sip] RFC 4028 (Session Timer) related question<= /span>

>

> Sergey,

>

> For this scenario to make sense there should be a proxy involved tha= t is

>

> interested in having a session timer. If there was, then it would in= sert

>

> a Session-Expires into reinvite of step 4, and A would respond,

> reestablishing the timer.

>

> If there is no proxy doing this, then there is no need for a session=

> timer to be established. If A wants to periodically check the status= of

> the session, it may do so an any time by sending a reinvite.<= /span>

>

>       Paul

>

> Sergey Markovich wrote:

>> We have the following scenario:

>>

>> 

>>

>> 1.       A  has Session Timer= mechanism enabled.

>>

>> 2.       A calls B,  the call= is established

>>

>> 3.       A is sending reINVITEs wi= th "Session-Expires" header to B

>> periodically. B is replying  with OK without "Session-= Expires" or

>> "Supported:timer", i.e. B does not support the Session= Timer

> mechanism,

>> A is a refresher.

>>

>> 4.       B puts A on hold, i.e. it= sends SDP related reINVITE without

>> "Session-Expires" or "Supported:timer"

>>

>> 5.       A  replies with OK w= ithout "Session-Expires" and it stops

>> (disables) the mechanism, i.e. no session timer related callback= s

>> anymore, the application does not do refresh (does not send reIN= VITEs)

>

>> anymore.

>>

>> 

>>

>> I am not sure that step 5 is RFC 4028 compliant.

>>

>> I know that the default value of "Session-Expires" is = infinity, but I

>> think it makes sense only when the sending party (B) DOES suppor= t the

>> mechanism (i.e. does include "Supported:timer", but do= es not include

>> "Session-Expires" in the reINVITE). In that case the r= eINVITE can be

>> used for the negotiation of the mechanism parameters. But in our= case

>> the reINVITE from step 4 has to be treated as "refresh"= ; only (because

>> after step 4 A knows that B is alive). So A has to restart the t= imer

> but

>> not to disable the mechanism.

>>

>> 

>>

>> It would be appreciated if you comment what should we do in step= 5.

>>

>> 

>>

>> Thanks a lot,

>>

>> 

>>

>> Sergey

>>

>> 

>>

>>

>>

> --------------------------------------------------------------------= ----

>> _______________________________________________

>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

>> This list is for NEW development of the core SIP Protocol=

>> Use sip-impl= ementors@cs.columbia.edu for questions on current sip

>> Use sipping@ietf.org for= new developments on the application of sip

>

>

> _______________________________________________

> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

> This list is for NEW development of the core SIP Protocol

> Use sip-implemen= tors@cs.columbia.edu for questions on current sip

> Use sipping@ietf.org for new= developments on the application of sip

>


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


------=_Part_10522_6538732.1147804940082-- --===============1014346282== 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 --===============1014346282==-- From sip-bounces@ietf.org Tue May 16 14:57:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4hg-0008Q8-ON; Tue, 16 May 2006 14:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4hg-0008Q3-3p for sip@ietf.org; Tue, 16 May 2006 14:55:32 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4he-0006lL-NC for sip@ietf.org; Tue, 16 May 2006 14:55:32 -0400 Received: (qmail 5488 invoked by uid 0); 16 May 2006 18:55:28 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 16 May 2006 18:55:28 -0000 Message-ID: <002901c6791a$48167620$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <446955E0.70506@cisco.com> <001001c678b3$16c4e780$31713b51@BEMBUSTER> <446975C7.3080006@cisco.com> Subject: Re: [Sip] comments on draft-ietf-sip-fork-loop-fix-01 Date: Tue, 16 May 2006 20:55:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline > inline. > > Jeroen van Bemmel wrote: > >>>> These requirements and the recommendation to use the loop-detection >>>> mechanisms from RFC 3261 make the favorable trade of exponential >>>> message growth for work that is at worst case order n^2 as a message >>>> crosses n proxies. Specifically, this work is order m*n where m is >>>> the number of proxies in the path that fork the request to more than >>>> one location. In practice, m is expected to be small. >>> >>> >>> You should explain what this work is - checking each of the N via >>> headers. You also don't explicitly say that this n^2 work is spread >>> across n proxies. Its only N at any particular proxy. This is important >>> because, as I argued at the mike, I think the constant in front of this >>> is sufficiently small to be unimportant. >>> >> >> I would expect that the bulk of the work is not inspecting the Via >> headers, but rather calculating the digest for distinguishing loops from >> spirals. > > Sure. But you only need to do that when there is a loop of any sort. In > other words, you first check to see if your address is on the Via list. > Only if its there do you bother to check if it was a loop vs. a spiral. > There are 2 points at which a proxy calculates a digest: upon reception (RFC3261 16.3 point 4) and when forwarding (RFC3261 16.6 point 8). You can avoid the first when there is no matching via header, and you can avoid the second when you already calculated the first, but it will have to be performed once for each passage of a request (before translation), regardless whether there is a loop or not. > > >> And you're trading *potential* (typically very rare) exponential message >> growth for *guaranteed* (always, for every forked request) order n^2 >> work. > > Well, the huge potential damage from this attack really does require this > tradeoff. I still don't think the work is that significant. Its O(N) on > each proxy and I really do think this constant is very small. Just the > time it takes to find your own address in the Via list. > It's not that I disagree with the necessity, just that it should be made explicit what is being traded-off here 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 May 16 15:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4m0-0000sL-Ut; Tue, 16 May 2006 15:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4lz-0000sG-O1 for sip@ietf.org; Tue, 16 May 2006 14:59:59 -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 1Fg4lz-0007Bg-4s for sip@ietf.org; Tue, 16 May 2006 14:59:59 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 16 May 2006 11:59:58 -0700 X-IronPort-AV: i="4.05,134,1146466800"; d="scan'208"; a="322407066:sNHT2212155682" 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/8.12.11) with ESMTP id k4GIxvta019124; Tue, 16 May 2006 11:59:57 -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 k4GIxvJj005738; Tue, 16 May 2006 11:59:57 -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.211); Tue, 16 May 2006 11:59:57 -0700 Received: from [10.21.90.228] ([10.21.90.228]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 11:59:56 -0700 Message-ID: <446A212B.9020608@cisco.com> Date: Tue, 16 May 2006 14:59:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sergey Markovich Subject: Re: [Sip] RFC 4028 (Session Timer) related question References: <395FBEF8576A0743B44A7C362541CBB3725063@rvnj-mail1.RADVISION.com> In-Reply-To: <395FBEF8576A0743B44A7C362541CBB3725063@rvnj-mail1.RADVISION.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 18:59:56.0884 (UTC) FILETIME=[EC65C140:01C6791A] DKIM-Signature: a=rsa-sha1; q=dns; l=6253; t=1147805997; x=1148669997; c=relaxed/simple; s=sjdkim6001; 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]=20RFC=204028=20(Session=20Timer)=20related=20question; X=v=3Dcisco.com=3B=20h=3D6U2TyJS/L8CBefAFr2aYnfFZ0Gs=3D; b=FoxzguLkt2Uu98cGe8KbLAe0AbMmCM5zc9CNsXBsZtNYNf3LRgOmx2Mvx5YSSadCOeOuD0tQ +L2B5v7NTIw8aO36KwPGUTEW4bAmm9oT9Jv3heizTCYANFeusgc0c3vF; 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: ba0d4c5f57f7c289496fce758bbf4798 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 Sergey, In the situation you describe there is no value to using the session timer mechanism. Since A is a (B2B)UA, it is free to send a reinvite any time it wants to check on its session with B or C. To do this without perturbing the call, it can send an offerless reinvite to B, take the answer and send it as an offer in a reinvite to C, etc. Or it could simplify and simply send an OPTIONS periodically to B and C. Session-Timer is really only of importance to stateful proxies. Paul Sergey Markovich wrote: > > Paul, > > I checked with our customer. A is a server but it is B2BUA and not a proxy. > > A is interested to know that B is alive. So there is no proxy. So the > scenario is the following: > > 1. B and C are endpoints. They do not know anything about Session > Timer mechanism. > 2. A is a B2BUA. It implements Session Timer mechanism. > 3. C calls A, A calls B, both calls are established. > 4. A is sending reINVITEs with "Session-Expires" header to B > periodically. B is replying with OK without "Session-Expires" or > "Supported:timer", i.e. B does not support the Session Timer mechanism, > A is a refresher. > > 5. Probably the same happens between A and C (on the other leg of > B2BUA) > 6. B puts A on hold, i.e. it sends SDP related reINVITE without > "Session-Expires" or "Supported:timer" > 7. A replies with OK without "Session-Expires" and it > stops(disables) the mechanism, i.e. no session timer related callbacks > anymore, the application does not do refresh (does not send reINVITEs) > anymore. > > Thank you, > > Sergey > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, May 16, 2006 12:16 PM > To: Sergey Markovich > Cc: sip@ietf.org > Subject: Re: [Sip] RFC 4028 (Session Timer) related question > > Sergy, > > Can you restate your problem, showing both UAs and the proxy, and what > > each does? > > Paul > > Sergey Markovich wrote: > >> Paul, > >> > >> A is a proxy in this scenario. Probably I was wrong when I said "A calls > >> B". A just forwards initial INVITE from somebody else to B. B is an > >> endpoint. > >> > >> Sergey > >> > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, May 15, 2006 5:46 PM > >> To: Sergey Markovich > >> Cc: sip@ietf.org > >> Subject: Re: [Sip] RFC 4028 (Session Timer) related question > >> > >> Sergey, > >> > >> For this scenario to make sense there should be a proxy involved that is > >> > >> interested in having a session timer. If there was, then it would insert > >> > >> a Session-Expires into reinvite of step 4, and A would respond, > >> reestablishing the timer. > >> > >> If there is no proxy doing this, then there is no need for a session > >> timer to be established. If A wants to periodically check the status of > >> the session, it may do so an any time by sending a reinvite. > >> > >> Paul > >> > >> Sergey Markovich wrote: > >> > We have the following scenario: > >> > > >> > > >> > > >> > 1. A has Session Timer mechanism enabled. > >> > > >> > 2. A calls B, the call is established > >> > > >> > 3. A is sending reINVITEs with "Session-Expires" header to B > >> > periodically. B is replying with OK without "Session-Expires" or > >> > "Supported:timer", i.e. B does not support the Session Timer > >> mechanism, > >> > A is a refresher. > >> > > >> > 4. B puts A on hold, i.e. it sends SDP related reINVITE without > >> > "Session-Expires" or "Supported:timer" > >> > > >> > 5. A replies with OK without "Session-Expires" and it stops > >> > (disables) the mechanism, i.e. no session timer related callbacks > >> > anymore, the application does not do refresh (does not send reINVITEs) > >> > >> > anymore. > >> > > >> > > >> > > >> > I am not sure that step 5 is RFC 4028 compliant. > >> > > >> > I know that the default value of "Session-Expires" is infinity, but I > >> > think it makes sense only when the sending party (B) DOES support the > >> > mechanism (i.e. does include "Supported:timer", but does not include > >> > "Session-Expires" in the reINVITE). In that case the reINVITE can be > >> > used for the negotiation of the mechanism parameters. But in our case > >> > the reINVITE from step 4 has to be treated as "refresh" only (because > >> > after step 4 A knows that B is alive). So A has to restart the timer > >> but > >> > not to disable the mechanism. > >> > > >> > > >> > > >> > It would be appreciated if you comment what should we do in step 5. > >> > > >> > > >> > > >> > Thanks a lot, > >> > > >> > > >> > > >> > Sergey > >> > > >> > > >> > > >> > > >> > > >> ------------------------------------------------------------------------ > >> > _______________________________________________ > >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > This list is for NEW development of the core SIP Protocol > >> > Use sip-implementors@cs.columbia.edu for questions on current sip > >> > Use sipping@ietf.org for new developments on the application of sip > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 16 18:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7rO-0003Sa-1I; Tue, 16 May 2006 18:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7rM-0003S2-Km; Tue, 16 May 2006 18:17:44 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7rL-0002p3-C2; Tue, 16 May 2006 18:17:44 -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.4) with ESMTP id k4GMHfhI087499 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 16 May 2006 17:17:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Tue, 16 May 2006 17:17:39 -0500 To: sip@ietf.org, sipping@ietf.org X-Mailer: Apple Mail (2.749.3) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Sip] Submission of sip-sec-flows-00 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All - I've just submitted http://www.nostrum.com/~rjsparks/draft-ietf-sip-sec-flows-00.txt at the request of the SIP and SIPPING chairs. This is a zero-change update (except for the filename change and a note that no changes were made) to simplify the chairs administrative efforts. We have started work on the next additions (we'll be pulling in the work Vijay started with tls-examples and capturing some additional SIPS information) but those changes are not reflected in this version. They will be reflected in an update before IETF66. Note that this message was crossposted to SIP and SIPPING. Replies, if any, should go only to SIP. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 16 18:23:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7vU-0005ng-9X; Tue, 16 May 2006 18:22:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7vT-0005nI-0N for sip@ietf.org; Tue, 16 May 2006 18:21:59 -0400 Received: from spark.hss.co.in ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7vP-00034H-1C for sip@ietf.org; Tue, 16 May 2006 18:21:58 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by spark.hss.co.in (8.13.6/8.13.6) with ESMTP id k4GMEfIi028874 for ; Wed, 17 May 2006 03:44:42 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k4GMMpT06338 for ; Wed, 17 May 2006 03:52:51 +0530 (IST) From: Ashutos Rath To: sip@ietf.org Message-ID: Date: Wed, 17 May 2006 03:54:19 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 17/05/2006 03:51:49 AM MIME-Version: 1.0 X-Spam-Score: 1.9 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] Ashutos Rath 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: , Content-Type: multipart/mixed; boundary="===============0839200931==" Errors-To: sip-bounces@ietf.org --===============0839200931== Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 05/03/2006 and will not return until 05/31/2006.

I will respond to your message when I return.

"DISCLAIMER: This message is proprietary to Flextronics Software
Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus." --===============0839200931== 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 --===============0839200931==-- From sip-bounces@ietf.org Tue May 16 18:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg8NW-0002y7-7U; Tue, 16 May 2006 18:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg8NV-0002y2-Ia for sip@ietf.org; Tue, 16 May 2006 18:50:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg8NV-0004Vu-8c for sip@ietf.org; Tue, 16 May 2006 18:50:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4GMojM07493 for ; Tue, 16 May 2006 18:50:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6793B.2A540134" Date: Tue, 16 May 2006 17:50:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09B01BBF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-audet-sip-sips-guidelines-01.txt Thread-Index: AcZ1/o0Vd+KWz9boSS64Nbabk/3RyADO/jVw From: "Francois Audet" To: "SIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [Sip] FW: I-D ACTION:draft-audet-sip-sips-guidelines-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6793B.2A540134 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please have a look at the following updated draft.=20 Comments welcome. PS: Paul Kyzivat already spotted that I've been using ";transport=3Dx" as a contact header parameter in the examples instead of as a sip URI parameter. This will be fixed in the next up-issue. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Friday, May 12, 2006 12:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-audet-sip-sips-guidelines-01.txt=20 >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Guidelines for the use of the SIPS=20 > URI Scheme in the Session Initiation Protocol (SIP) > Author(s) : F. Audet > Filename : draft-audet-sip-sips-guidelines-01.txt > Pages : 20 > Date : 2006-5-12 > =09 > This document provides clarifications and guidelines concerning the > use of SIPS URI Scheme in the Session Initiation Protocol (SIP). >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-audet-sip-sips-guidelines-01.t xt 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 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 username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-audet-sip-sips-guidelines-01.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-audet-sip-sips-guidelines-01.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. =09 =09 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_01C6793B.2A540134 Content-Type: application/octet-stream; name="draft-audet-sip-sips-guidelines-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-audet-sip-sips-guidelines-01.URL Content-Disposition: attachment; filename="draft-audet-sip-sips-guidelines-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1hdWRldC1zaXAtc2lwcy1ndWlkZWxpbmVzLTAxLnR4dA0K ------_=_NextPart_001_01C6793B.2A540134 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_01C6793B.2A540134-- From sip-bounces@ietf.org Wed May 17 01:58:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgF0h-0004uL-U3; Wed, 17 May 2006 01:55:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgF0g-0004uF-3J for sip@ietf.org; Wed, 17 May 2006 01:55:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgF0Y-0001wv-G3 for sip@ietf.org; Wed, 17 May 2006 01:55:46 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 22:55:41 -0700 X-IronPort-AV: i="4.05,135,1146466800"; d="scan'208"; a="1807577374:sNHT33870890" 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/8.12.11) with ESMTP id k4H5tfLM000869; Tue, 16 May 2006 22:55:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4H5tfJj022546; Tue, 16 May 2006 22:55:41 -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, 16 May 2006 22:55:41 -0700 Received: from [65.241.177.248] ([10.21.121.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 22:55:40 -0700 Message-ID: <446ABAD8.3010900@cisco.com> Date: Wed, 17 May 2006 01:55:36 -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: "Tan, Ya-Ching" Subject: Re: [Sip] Minor comments on draft-ietf-sip-gruu-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 05:55:41.0253 (UTC) FILETIME=[87780750:01C67976] DKIM-Signature: a=rsa-sha1; q=dns; l=2164; t=1147845341; x=1148709341; c=relaxed/simple; s=sjdkim8001; 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]=20Minor=20comments=20on=20draft-ietf-sip-gruu-07.txt; X=v=3Dcisco.com=3B=20h=3DJWXtWbz2seH1B+3BA9jE4UvqX/c=3D; b=Vu/44hQWwWXtK6iBhdTAu9JrrPq0ORS1UiJPOwPTx2T8DyTnS+A/rwzvzCgwNjsRfBBnjpvI jl0i07AazxBtsgOJOcPbt4I867X4JVnGk8F57kb2m2RnYx7DahSM4QXm; 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: 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: , Errors-To: sip-bounces@ietf.org Thanks for the comments. Responses inline. Tan, Ya-Ching wrote: > - Section 10 Grammar does not mention the new "+sip.instance" parameter > for the Contact header, but includes : > instance-val = *uric ; defined in RFC 2396 (should be RFC 3986) This is leftover grammar - removed. > > - The SUBSCRIBE message on page 27 and page 28 : > o The URI in the To header field must be enclosed in "<" and ">". As > it is now, the "opaque" and "grid" become To header parameters. Great catch. Fixed. > o Allow: INVITE, OPTIONS, CANCEL, BYE, ACK should also include > SUBSCRIBE and NOTIFY Well, its SUBSCRIBE for one of the UAs and NOTIFY for the other, but you are correct that SUB/NOT needs to be correctly included here. Thanks. > > - Page 5 : ">From" should be "From" fixed. > > - Page 12 : "reuqest" should be "request" fixed. > > - Section 7.1.1.1 : "..., it MUST use [14]" => "..., it MUST follow the > procedures defined in [14]". fixed. > > - Section 8.2.1 "(allowing mutiple flows.." has no closing bracket. fixed. > > - Section 8.2.3 "(which happens when the client.." has no closing > bracket. fixed. > > - The last sentence on page 21 makes no sense. "This information may be > present from the hint if the topmost Route header field URI, if the > proxy used that technique". Right. The first 'if' should be 'in'. Fixed. > > - Request-URI has been written as "Request URI", "request URI" (eg. > 8.1.3 "the incoming request URI") as well as "Request-URI" throughout > the document. Fixed to all be Request-URI > > - And we have "AOR" and "AoR" Fixed to be AOR. > > - Section 14 should register "Predefined Values : None" for all the new > parameters. Fixed. Thanks for your 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 From sip-bounces@ietf.org Wed May 17 02:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpz-0005lr-DQ; Wed, 17 May 2006 02:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpx-0005lg-CH for sip@ietf.org; Wed, 17 May 2006 02:48:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFpv-0004f1-QY for sip@ietf.org; Wed, 17 May 2006 02:48:49 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 23:48:48 -0700 X-IronPort-AV: i="4.05,136,1146466800"; d="scan'208"; a="1807605499:sNHT32195224" 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/8.12.11) with ESMTP id k4H6mlsr018131; Tue, 16 May 2006 23:48:47 -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 k4H6mosF009019; Tue, 16 May 2006 23:48:50 -0700 (PDT) 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.211); Tue, 16 May 2006 23:48:47 -0700 Received: from [65.241.177.248] ([10.21.121.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 23:48:46 -0700 Message-ID: <446A2FF1.6020807@cisco.com> Date: Tue, 16 May 2006 16:02:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> In-Reply-To: <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 06:48:46.0487 (UTC) FILETIME=[F2042A70:01C6797D] DKIM-Signature: a=rsa-sha1; q=dns; l=2399; t=1147848527; x=1148712527; c=relaxed/simple; s=sjdkim7001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3Dw12oKMAuau5dUPBTtHVgxDg20OE=3D; b=U5bxbF4DJ4BatwHfLgg7mF2VZZ4X6ZRTO4J7AZAbnZSAcW0rFdgyBV8sCAQJwLYRU/KTz6uO uC2dyU9ZKQZ9akq9R4T69lw4/SyzTfTCjKKsmWJPOzcbkUXk0+PT7uqO; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: SIP IETF , 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'd suggest that it probably should be standards track. URI parameters are a bigger deal than headers, I think, since they are really making changes to the fundamental SIP addressing architecture. I don't think that is something we want everyone doing. -Jonathan R. Cullen Jennings wrote: > > On May 9, 2006, at 8:54 PM, Dean Willis wrote: > >> >> RFC 3969 defines the registry for SIP/SIPS URI parameters. >> >> It currently says: >> >> 4.2. Registration Policy for SIP and SIPS URI Parameters >> >> As per the terminology in RFC 2434 [4], the registration policy for >> SIP and SIPS URI parameters shall be "Specification Required". >> >> FFrom sip-bounces@ietf.org Wed May 17 02:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpz-0005lr-DQ; Wed, 17 May 2006 02:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpx-0005lg-CH for sip@ietf.org; Wed, 17 May 2006 02:48:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFpv-0004f1-QY for sip@ietf.org; Wed, 17 May 2006 02:48:49 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 23:48:48 -0700 X-IronPort-AV: i="4.05,136,1146466800"; d="scan'208"; a="1807605499:sNHT32195224" 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/8.12.11) with ESMTP id k4H6mlsr018131; Tue, 16 May 2006 23:48:47 -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 k4H6mosF009019; Tue, 16 May 2006 23:48:50 -0700 (PDT) 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.211); Tue, 16 May 2006 23:48:47 -0700 Received: from [65.241.177.248] ([10.21.121.229]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 23:48:46 -0700 Message-ID: <446A2FF1.6020807@cisco.com> Date: Tue, 16 May 2006 16:02:57 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> In-Reply-To: <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 06:48:46.0487 (UTC) FILETIME=[F2042A70:01C6797D] DKIM-Signature: a=rsa-sha1; q=dns; l=2399; t=1147848527; x=1148712527; c=relaxed/simple; s=sjdkim7001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3Dw12oKMAuau5dUPBTtHVgxDg20OE=3D; b=U5bxbF4DJ4BatwHfLgg7mF2VZZ4X6ZRTO4J7AZAbnZSAcW0rFdgyBV8sCAQJwLYRU/KTz6uO uC2dyU9ZKQZ9akq9R4T69lw4/SyzTfTCjKKsmWJPOzcbkUXk0+PT7uqO; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: SIP IETF , 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'd suggest that it probably should be standards track. URI parameters are a bigger deal than headers, I think, since they are really making changes to the fundamental SIP addressing architecture. I don't think that is something we want everyone doing. -Jonathan R. Cullen Jennings wrote: > > On May 9, 2006, at 8:54 PM, Dean Willis wrote: > >> >> RFC 3969 defines the registry for SIP/SIPS URI parameters. >> >> It currently says: >> >> 4.2. Registration Policy for SIP and SIPS URI Parameters >> >> As per the terminology in RFC 2434 [4], the registration policy for >> SIP and SIPS URI parameters shall be "Specification Required". >> >> For the purposes of this registry, the parameter for which IANA >> registration is requested MUST be defined by a standards-track RFC. >> >> >> Note that the above two paragraphs seem to be self contradictory. >> "Specification Required" means 3GPP and recognized bodies can define >> parameters by publishing specifications. But"Standards Track RFC" >> means only IETF can do so, and it has to be done with an IETF- >> consensus standards-track document. >> >> Note that the IANA registry currently says: >> >> >> SIP/SIPS URI Parameters RFC3969 Specification Required >> >> SIP/SIPS URI Parameters - per [RFC3969] >> (New registrations are via Specification Required) >> >> This means that the current IANA policy for this registry is >> "Specification Required". >> >> >> Which did we mean? > > > We might want to check with Allison on history of this but my vague > recollection was last time we discussed this, we decided we meant > "Standards Track". I forget the details and may be totally wrong. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 17 02:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFq0-0005ly-50; Wed, 17 May 2006 02:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpy-0005lm-G5 for sip@ietf.org; Wed, 17 May 2006 02:48:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFpx-0004f3-4Z for sip@ietf.org; Wed, 17 May 2006 02:48:50 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 23:48:49 -0700 X-IronPort-AV: i="4.05,136,1146466800"; d="scan'208"; a="1807605510:sNHT31418952" 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/8.12.11) with ESMTP id k4H6mmlk018139 for ; Tue, 16 May 2006 23:48:48 -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 k4H6mmJj009106 for ; Tue, 16 May 2006 23:48:48 -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.211); Tue, 16 May 2006 23:48:48 -0700 Received: from [65.241.177.248] ([10.21.121.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 23:48:48 -0700 Message-ID: <446A71D4.4090409@cisco.com> Date: Tue, 16 May 2006 20:44: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 06:48:48.0320 (UTC) FILETIME=[F31BDC00:01C6797D] DKIM-Signature: a=rsa-sha1; q=dns; l=2588; t=1147848528; x=1148712528; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisor the purposes of this registry, the parameter for which IANA >> registration is requested MUST be defined by a standards-track RFC. >> >> >> Note that the above two paragraphs seem to be self contradictory. >> "Specification Required" means 3GPP and recognized bodies can define >> parameters by publishing specifications. But"Standards Track RFC" >> means only IETF can do so, and it has to be done with an IETF- >> consensus standards-track document. >> >> Note that the IANA registry currently says: >> >> >> SIP/SIPS URI Parameters RFC3969 Specification Required >> >> SIP/SIPS URI Parameters - per [RFC3969] >> (New registrations are via Specification Required) >> >> This means that the current IANA policy for this registry is >> "Specification Required". >> >> >> Which did we mean? > > > We might want to check with Allison on history of this but my vague > recollection was last time we discussed this, we decided we meant > "Standards Track". I forget the details and may be totally wrong. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 17 02:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFq0-0005ly-50; Wed, 17 May 2006 02:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFpy-0005lm-G5 for sip@ietf.org; Wed, 17 May 2006 02:48:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFpx-0004f3-4Z for sip@ietf.org; Wed, 17 May 2006 02:48:50 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 May 2006 23:48:49 -0700 X-IronPort-AV: i="4.05,136,1146466800"; d="scan'208"; a="1807605510:sNHT31418952" 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/8.12.11) with ESMTP id k4H6mmlk018139 for ; Tue, 16 May 2006 23:48:48 -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 k4H6mmJj009106 for ; Tue, 16 May 2006 23:48:48 -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.211); Tue, 16 May 2006 23:48:48 -0700 Received: from [65.241.177.248] ([10.21.121.229]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 23:48:48 -0700 Message-ID: <446A71D4.4090409@cisco.com> Date: Tue, 16 May 2006 20:44: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: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 06:48:48.0320 (UTC) FILETIME=[F31BDC00:01C6797D] DKIM-Signature: a=rsa-sha1; q=dns; l=2588; t=1147848528; x=1148712528; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3DR0umInZz2wHkMXhC3KWPWOAbKy4=3D; b=POz4o+w0H/SYKMtcn+oURNZkK0Ig73VplwicY9J1vYA8yg8fFFZRLhqLbMJnYuMFpOtWgl3M B5sN7dzG0vVsD2Fp+diwQFGWdWLI03nz48TCV8IyeDw4Rvo/KafS84nt; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] Comments on draft-audet-sip-sips-guidelines X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Thanks a lot for taking a stab at this. Its long overdue. I have lots of comments and thoughts on this, but wanted to start with some high level issues that I think we need to agree on. Firstly, I think that the sips mechanism is both underspecified and broken. Its broken because there are really no guarantees with it at all. As you point out, a UAS that receives a request with r-uri that is sips can't REALLY tell if it was TLS all the way (since it might have been upgraded). Furthermore, TLS is not strictly required, and thus its not clear what the guarantee actually is. I think we first need to fix this problem. I'd propose that, to be useful, sips has to do as it implies - it means that each and every link from UAC to UAS was secure. This means two things: 1. SIPS requires the usage of TLS at every hop - none of this weasel words on IPSec 2. there is no upgrading or downgrading, period With these two rules, it becomes much clear what kind of benefits are provided by sips. Every hop is secure with TLS, period. No ifs, ands or buts about it. If a UAS gets a request and the r-uri is sips, it means every hop was TLS. If it gets a request and the r-uri is sip, there is no guarantee about whether the hops were secure (they may or may not have been). It also helps clarify the distinction between sips and transport=tls. Namely, transport=tls just means that a particular hop uses TLS. It implies nothing about the security of links upstream or downstream to it. sips, however, implies that every single hop towards the resource was secure. Moving on to some of the details, I think we can simplify the registration procedure further. I would propose that it is never necessary to include separate contacts for sip and sips. If a registration is sent such that each hop was over TLS (done by having the r-uri in the registration be a sips URI), then that contact (and the associated secure path URI) can be used for requests sent to sip or sips AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a sips version of the contact. If a request is sent to a SIP AOR, the r-uri is a sip version of the contact. Thoughts? -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 co.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3DR0umInZz2wHkMXhC3KWPWOAbKy4=3D; b=POz4o+w0H/SYKMtcn+oURNZkK0Ig73VplwicY9J1vYA8yg8fFFZRLhqLbMJnYuMFpOtWgl3M B5sN7dzG0vVsD2Fp+diwQFGWdWLI03nz48TCV8IyeDw4Rvo/KafS84nt; Authentication-Results: sj-dkim-7.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] Comments on draft-audet-sip-sips-guidelines X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Thanks a lot for taking a stab at this. Its long overdue. I have lots of comments and thoughts on this, but wanted to start with some high level issues that I think we need to agree on. Firstly, I think that the sips mechanism is both underspecified and broken. Its broken because there are really no guarantees with it at all. As you point out, a UAS that receives a request with r-uri that is sips can't REALLY tell if it was TLS all the way (since it might have been upgraded). Furthermore, TLS is not strictly required, and thus its not clear what the guarantee actually is. I think we first need to fix this problem. I'd propose that, to be useful, sips has to do as it implies - it means that each and every link from UAC to UAS was secure. This means two things: 1. SIPS requires the usage of TLS at every hop - none of this weasel words on IPSec 2. there is no upgrading or downgrading, period With these two rules, it becomes much clear what kind of benefits are provided by sips. Every hop is secure with TLS, period. No ifs, ands or buts about it. If a UAS gets a request and the r-uri is sips, it means every hop was TLS. If it gets a request and the r-uri is sip, there is no guarantee about whether the hops were secure (they may or may not have been). It also helps clarify the distinction between sips and transport=tls. Namely, transport=tls just means that a particular hop uses TLS. It implies nothing about the security of links upstream or downstream to it. sips, however, implies that every single hop towards the resource was secure. Moving on to some of the details, I think we can simplify the registration procedure further. I would propose that it is never necessary to include separate contacts for sip and sips. If a registration is sent such that each hop was over TLS (done by having the r-uri in the registration be a sips URI), then that contact (and the associated secure path URI) can be used for requests sent to sip or sips AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a sips version of the contact. If a request is sent to a SIP AOR, the r-uri is a sip version of the contact. Thoughts? -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 May 17 03:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgG9f-0005Uu-I2; Wed, 17 May 2006 03:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgG9e-0005Up-5h for sip@ietf.org; Wed, 17 May 2006 03:09:10 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgG9c-0005P8-Qi for sip@ietf.org; Wed, 17 May 2006 03:09:10 -0400 Received: by tutpro.com (Postfix, from userid 65534) id C5226140017; Wed, 17 May 2006 10:08:58 +0300 (EEST) Received: from rautu (eukaryote220.gprs.dnafinland.fi [62.78.106.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 1A1A213F989; Wed, 17 May 2006 10:08:53 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 567E2F0837; Wed, 17 May 2006 10:08:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17514.52227.314050.685935@rautu.tutpro.com> Date: Wed, 17 May 2006 10:08:51 +0300 From: Juha Heinanen To: Jonathan Rosenberg Subject: [Sip] Comments on draft-audet-sip-sips-guidelines In-Reply-To: <446A71D4.4090409@cisco.com> References: <446A71D4.4090409@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 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 Jonathan Rosenberg writes: > 1. SIPS requires the usage of TLS at every hop - none of this weasel > words on IPSec > > 2. there is no upgrading or downgrading, period i fully support these and also the once below: > It also helps clarify the distinction between sips and transport=tls. > Namely, transport=tls just means that a particular hop uses TLS. > If a request is sent to a SIPS AOR, the proxy sets the r-uri to a > sips version of the contact. If a request is sent to a SIP AOR, the > r-uri is a sip version of the contact. lets get an rfc out quickly that fixes rfc3261 based on jonathan's proposal. -- 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 Wed May 17 09:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLwv-0006zQ-PD; Wed, 17 May 2006 09:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLwu-0006xf-EA for sip@ietf.org; Wed, 17 May 2006 09:20:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLwr-0000D3-2o for sip@ietf.org; Wed, 17 May 2006 09:20:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 17 May 2006 06:20:20 -0700 X-IronPort-AV: i="4.05,137,1146466800"; d="scan'208"; a="1807800886:sNHT100636956" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDKKu6005013; Wed, 17 May 2006 06:20:20 -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 k4HDKKB9012718; Wed, 17 May 2006 06:20:20 -0700 (PDT) Received: from [10.1.31.152] (sjc-vpn4-900.cisco.com [10.21.83.131]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HDHoLC015545; Wed, 17 May 2006 06:17:50 -0700 In-Reply-To: <446A71D4.4090409@cisco.com> References: <446A71D4.4090409@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 09:20:12 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-2.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=3473; t=1147872020; x=1148736020; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Dn1L1CCXXqIQr6cuYWIcrgB9pc7g=3D; b=pZjDEbD6lhWcoRYjYLI/+rg3Gc+X8xvIFQT7r1gj1qlpCUczVwxo3aPKW50Jetgy7lClkalE WCPyl1wATrGWstBkkpQLr7JAvmqnFu3kEbaOVCHaoUS2WtLT7t351Lqm; X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 May 16, 2006, at 8:44 PM, Jonathan Rosenberg wrote: > I'd propose that, to be useful, sips has to do as it implies - it > means that each and every link from UAC to UAS was secure. This > means two things: > > 1. SIPS requires the usage of TLS at every hop - none of this > weasel words on IPSec > Uh, why? This contradicts what you said above, which was that "each and every link...was secure". If that in fact is the desired semantic, how can you argue that, for example, a direct UAC-UAS IPSEC tunnel using AES-256 and keys delivered by NSA agents is not secure, while a multi-hop TLS connection where each hop uses null-encryption cypher or 40-bit keys is secure? I'd have less problem with this if SIPS was redefined to mean "each hop used TLS" and said NOTHING about whether the end-to-end communication was secure or not. On the other hand, what would be more useful would in fact be an end- to-end assertion about what level of security the UAS can count on. > 2. there is no upgrading or downgrading, period > I'm OK with this. > > With these two rules, it becomes much clear what kind of benefits > are provided by sips. Every hop is secure with TLS, period. I'm OK with this if you simply say "used TLS" as opposed to "secure with TLS". I would still argue that you'd need strong caveats that this does not actually say much if anything about how secure the end- to-end communication was unless the transport connection is direct UA- UA with no proxy hops. Cheers, Dave. > No ifs, ands or buts about it. If a UAS gets a request and the r- > uri is sips, it means every hop was TLS. If it gets a request and > the r-uri is sip, there is no guarantee about whether the hops were > secure (they may or may not have been). > > It also helps clarify the distinction between sips and > transport=tls. Namely, transport=tls just means that a particular > hop uses TLS. It implies nothing about the security of links > upstream or downstream to it. sips, however, implies that every > single hop towards the resource was secure. > > Moving on to some of the details, I think we can simplify the > registration procedure further. I would propose that it is never > necessary to include separate contacts for sip and sips. If a > registration is sent such that each hop was over TLS (done by > having the r-uri in the registration be a sips URI), then that > contact (and the associated secure path URI) can be used for > requests sent to sip or sips AOR. If a request is sent to a SIPS > AOR, the proxy sets the r-uri to a sips version of the contact. If > a request is sent to a SIP AOR, the r-uri is a sip version of the > contact. > > Thoughts? > > -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 May 17 09:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMIM-0007mU-49; Wed, 17 May 2006 09:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMIJ-0007fK-N2 for sip@ietf.org; Wed, 17 May 2006 09:42:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMII-0001c8-Ba for sip@ietf.org; Wed, 17 May 2006 09:42:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 17 May 2006 06:42:29 -0700 X-IronPort-AV: i="4.05,137,1146466800"; d="scan'208"; a="278245375:sNHT32472680" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDgST2002507; Wed, 17 May 2006 06:42:28 -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 k4HDgSB7005460; Wed, 17 May 2006 06:42:28 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn-hwcore-307.cisco.com [10.21.153.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HDduIe016037; Wed, 17 May 2006 06:39:58 -0700 Message-ID: <446B2842.90903@cisco.com> Date: Wed, 17 May 2006 06:42: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: David R Oran Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines References: <446A71D4.4090409@cisco.com> <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.com> In-Reply-To: <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.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=1395; t=1147873348; x=1148737348; c=relaxed/simple; s=sjdkim4001; 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]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Ds8zUC0Q9SWMTMp3DguG5z6igkVQ=3D; b=on5NmM5xj9It/OBFD7l+26fyodBbHnsMlkaWW3Hw5A/zQY+RZHc3vwCNkcx+9SzMvwZdmjhx poH67Fh3dg1zDHd+gzeNcClcE2vhGSXjhlyrepj3eoTJr88LBWqdSqQE; X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David R Oran wrote: > > On May 16, 2006, at 8:44 PM, Jonathan Rosenberg wrote: > >> I'd propose that, to be useful, sips has to do as it implies - it >> means that each and every link from UAC to UAS was secure. This >> means two things: >> >> 1. SIPS requires the usage of TLS at every hop - none of this weasel >> words on IPSec >> > Uh, why? This contradicts what you said above, which was that "each > and every link...was secure". If that in fact is the desired > semantic, how can you argue that, for example, a direct UAC-UAS IPSEC > tunnel using AES-256 and keys delivered by NSA agents is not secure, > while a multi-hop TLS connection where each hop uses null-encryption > cypher or 40-bit keys is secure? > > I'd have less problem with this if SIPS was redefined to mean "each > hop used TLS" and said NOTHING about whether the end-to-end > communication was secure or not. > > On the other hand, what would be more useful would in fact be an end- > to-end assertion about what level of security the UAS can count on. How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_ about whether the previous hop was TLS, how exactly can you detect that? Sips is nothing more than a request that good actors act good, and no amount of shoe pounding on podiums is going to elevate it to first class status. 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 Wed May 17 09:55:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMSC-0002is-VE; Wed, 17 May 2006 09:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMSA-0002hR-NB for sip@ietf.org; Wed, 17 May 2006 09:52:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMS9-0001z8-CP for sip@ietf.org; Wed, 17 May 2006 09:52:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 17 May 2006 06:52:40 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="1807820155:sNHT40046418" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDqeXx019630; Wed, 17 May 2006 06:52:40 -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 k4HDqeB9000491; Wed, 17 May 2006 06:52:40 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn-hwcore-307.cisco.com [10.21.153.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HDo9Rs016281; Wed, 17 May 2006 06:50:10 -0700 Message-ID: <446B2AA7.4010304@cisco.com> Date: Wed, 17 May 2006 06:52:39 -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: David R Oran Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines References: <446A71D4.4090409@cisco.com> <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.com> <446B2842.90903@cisco.com> <3171F384-A93B-48D8-A01E-458D8505AEF4@cisco.com> In-Reply-To: <3171F384-A93B-48D8-A01E-458D8505AEF4@cisco.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=1890; t=1147873960; x=1148737960; c=relaxed/simple; s=sjdkim3001; 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]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Ds8zUC0Q9SWMTMp3DguG5z6igkVQ=3D; b=swWKSzosGBp+c5juDbx+rpMdIN6N3+Dts3autAl+ZVdPIyw3j82sAxWPhjA0v5qRmdFkJmfj yYGvgTSiJfnOMa3pSAtRCtnLZwVddXm/KMu6GomVx6WhiMxWrlUUPHfD; X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org David R Oran wrote: > > On May 17, 2006, at 9:42 AM, Michael Thomas wrote: > >> David R Oran wrote: >> >>> >>> On May 16, 2006, at 8:44 PM, Jonathan Rosenberg wrote: >>> >>>> I'd propose that, to be useful, sips has to do as it implies - it >>>> means that each and every link from UAC to UAS was secure. This >>>> means two things: >>>> >>>> 1. SIPS requires the usage of TLS at every hop - none of this >>>> weasel words on IPSec >>>> >>> Uh, why? This contradicts what you said above, which was that >>> "each and every link...was secure". If that in fact is the >>> desired semantic, how can you argue that, for example, a direct >>> UAC-UAS IPSEC tunnel using AES-256 and keys delivered by NSA >>> agents is not secure, while a multi-hop TLS connection where each >>> hop uses null-encryption cypher or 40-bit keys is secure? >>> >>> I'd have less problem with this if SIPS was redefined to mean >>> "each hop used TLS" and said NOTHING about whether the end-to- end >>> communication was secure or not. >>> >>> On the other hand, what would be more useful would in fact be an >>> end- to-end assertion about what level of security the UAS can >>> count on. >> >> >> >> How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_ >> about whether >> the previous hop was TLS, how exactly can you detect that? Sips is >> nothing >> more than a request that good actors act good, and no amount of shoe >> pounding >> on podiums is going to elevate it to first class status. >> > I didn't say it was easy/possible to do. I said it would be more > useful :-) Well, the operative word here is "count". A UAS can't count on anything with SIPS because it has no way to verify against potential adversaries. No amount of words -- weasel or otherwise -- are going to change that. 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 Wed May 17 10:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFe-0006eu-D0; Wed, 17 May 2006 10:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFc-0006eA-9G for sip@ietf.org; Wed, 17 May 2006 10:43:48 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNFZ-0004eD-LD for sip@ietf.org; Wed, 17 May 2006 10:43:48 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 17 May 2006 20:30:09 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="67909180:sNHT30060396" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4HEfjDs005805 for ; Wed, 17 May 2006 22:41:46 +0800 (CST) Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 May 2006 22:43:41 +0800 Received: from [10.70.230.89] ([10.70.230.89]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 May 2006 22:43:40 +0800 Message-ID: <446B3696.4070408@cisco.com> Date: Wed, 17 May 2006 10:43:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines References: <446A71D4.4090409@cisco.com> In-Reply-To: <446A71D4.4090409@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 14:43:41.0097 (UTC) FILETIME=[4A209990:01C679C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: > Francois, > > Thanks a lot for taking a stab at this. Its long overdue. > > I have lots of comments and thoughts on this, but wanted to start with > some high level issues that I think we need to agree on. > > Firstly, I think that the sips mechanism is both underspecified and > broken. Its broken because there are really no guarantees with it at > all. Yeah. That is a problem. > As you point out, a UAS that receives a request with r-uri that is > sips can't REALLY tell if it was TLS all the way (since it might have > been upgraded). Furthermore, TLS is not strictly required, and thus its > not clear what the guarantee actually is. I think we first need to fix > this problem. > > I'd propose that, to be useful, sips has to do as it implies - it means > that each and every link from UAC to UAS was secure. This means two things: Yes. But we need to be very clear about how the applicable case is recognized. It is certain means of using SIPS that will provide this guarantee. Other usages of sips may not. I don't think it is yet clear exactly what those usages are, and that is part of the task. > 1. SIPS requires the usage of TLS at every hop - none of this weasel > words on IPSec I'm still on the fence on this one. IPSec has its uses, and people using it will want some guarantees of secure communication too. I don't have an answer here, but I fear if we don't accommodate it explicitly then people will just cheat. > 2. there is no upgrading or downgrading, period I think this depends on what you mean by upgrading and downgrading. Below you propose that the home proxy can take a single registered contact and convert it from sip to sips or visa versa depending on how the call reached the AOR. That seems like upgrading or downgrading to me. Also, I don't want to have to independently register to the sip and sips form of my AOR, and yet I want calls to both forms to be valid. That also implies some form of upgrading or downgrading somewhere. I think it is more a matter of in what circumstances an AOR may be upgraded or downgraded. It must be restricted to cases where it remains clear whether there is a secure path end to end. So, it should be ok for the originator of a request to upgrade (and maybe to downgrade), but it isn't ok for others along the path to *that* target to do so. Once it reaches that target (the AOR), then some other rules cut it. Since upgrading or downgrading along the path is a translation, it is already forbidden by 3261, so this perhaps only amounts to a clarification. B2BUAs may (as always) present a special concern. As a UA, it may be valid for one to upgrade or downgrade. But that may be very deceptive to the ultimate target. So this may require some special specifications. > With these two rules, it becomes much clear what kind of benefits are > provided by sips. Every hop is secure with TLS, period. There remains the problem that this is hop by hop, and any of those hops can lie. So the guarantee is always conditional. Paul > No ifs, ands or > buts about it. If a UAS gets a request and the r-uri is sips, it means > every hop was TLS. If it gets a request and the r-uri is sip, there is > no guarantee about whether the hops were secure (they may or may not > have been). > > It also helps clarify the distinction between sips and transport=tls. > Namely, transport=tls just means that a particular hop uses TLS. It > implies nothing about the security of links upstream or downstream to > it. sips, however, implies that every single hop towards the resource > was secure. > > Moving on to some of the details, I think we can simplify the > registration procedure further. I would propose that it is never > necessary to include separate contacts for sip and sips. If a > registration is sent such that each hop was over TLS (done by having the > r-uri in the registration be a sips URI), then that contact (and the > associated secure path URI) can be used for requests sent to sip or sips > AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a > sips version of the contact. If a request is sent to a SIP AOR, the > r-uri is a sip version of the contact. > > Thoughts? > > -Jonathan R. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 17 10:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFa-0006dn-6K; Wed, 17 May 2006 10:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFY-0006dd-EZ for sip@ietf.org; Wed, 17 May 2006 10:43:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMRq-0001wy-MB for sip@ietf.org; Wed, 17 May 2006 09:52:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgMKr-0005Dn-LP for sip@ietf.org; Wed, 17 May 2006 09:45:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 May 2006 06:45:09 -0700 X-IronPort-AV: i="4.05,137,1146466800"; d="scan'208"; a="278246927:sNHT33123868" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDj8kh021152; Wed, 17 May 2006 06:45:08 -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 k4HDj8Hc016174; Wed, 17 May 2006 06:45:08 -0700 (PDT) Received: from [10.1.31.152] (sjc-vpn4-900.cisco.com [10.21.83.131]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HDgan1016092; Wed, 17 May 2006 06:42:38 -0700 In-Reply-To: <446B2842.90903@cisco.com> References: <446A71D4.4090409@cisco.com> <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.com> <446B2842.90903@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3171F384-A93B-48D8-A01E-458D8505AEF4@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 09:44:57 -0400 To: Michael Thomas X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1599; t=1147873509; x=1148737509; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Dn1L1CCXXqIQr6cuYWIcrgB9pc7g=3D; b=IVuziKqoxQ8XN5rrrheb5s3jthONNrWBl7Wy0GBay8oeOISnyGMB7TVCa3F04bQ/yZy1gBt/ mdcYAsIfxlvqiaVuo6rEJuZ8RaHXkBOzjjvMtz6g0e9gM13iRm9NMnHU; X-Spam-Score: -2.6 (--) 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 May 17, 2006, at 9:42 AM, Michael Thomas wrote: > David R Oran wrote: > >> >> On May 16, 2006, at 8:44 PM, Jonathan Rosenberg wrote: >> >>> I'd propose that, to be useful, sips has to do as it implies - >>> it means that each and every link from UAC to UAS was secure. >>> This means two things: >>> >>> 1. SIPS requires the usage of TLS at every hop - none of this >>> weasel words on IPSec >>> >> Uh, why? This contradicts what you said above, which was that >> "each and every link...was secure". If that in fact is the >> desired semantic, how can you argue that, for example, a direct >> UAC-UAS IPSEC tunnel using AES-256 and keys delivered by NSA >> agents is not secure, while a multi-hop TLS connection where each >> hop uses null-encryption cypher or 40-bit keys is secure? >> >> I'd have less problem with this if SIPS was redefined to mean >> "each hop used TLS" and said NOTHING about whether the end-to- >> end communication was secure or not. >> >> On the other hand, what would be more useful would in fact be an >> end- to-end assertion about what level of security the UAS can >> count on. > > > How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_ > about whether > the previous hop was TLS, how exactly can you detect that? Sips is > nothing > more than a request that good actors act good, and no amount of > shoe pounding > on podiums is going to elevate it to first class status. > I didn't say it was easy/possible to do. I said it would be more 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 Wed May 17 10:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFe-0006eu-D0; Wed, 17 May 2006 10:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFc-0006eA-9G for sip@ietf.org; Wed, 17 May 2006 10:43:48 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNFZ-0004eD-LD for sip@ietf.org; Wed, 17 May 2006 10:43:48 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 17 May 2006 20:30:09 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="67909180:sNHT30060396" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4HEfjDs005805 for ; Wed, 17 May 2006 22:41:46 +0800 (CST) Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 May 2006 22:43:41 +0800 Received: from [10.70.230.89] ([10.70.230.89]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 May 2006 22:43:40 +0800 Message-ID: <446B3696.4070408@cisco.com> Date: Wed, 17 May 2006 10:43:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines References: <446A71D4.4090409@cisco.com> In-Reply-To: <446A71D4.4090409@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 14:43:41.0097 (UTC) FILETIME=[4A209990:01C679C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: > Francois, > > Thanks a lot for taking a stab at this. Its long overdue. > > I have lots of comments and thoughts on this, but wanted to start with > some high level issues that I think we need to agree on. > > Firstly, I think that the sips mechanism is both underspecified and > broken. Its broken because there are really no guarantees with it at > all. Yeah. That is a problem. > As you point out, a UAS that receives a request with r-uri that is > sips can't REALLY tell if it was TLS all the way (since it might have > been upgraded). Furthermore, TLS is not strictly required, and thus its > not clear what the guarantee actually is. I think we first need to fix > this problem. > > I'd propose that, to be useful, sips has to do as it implies - it means > that each and every link from UAC to UAS was secure. This means two things: Yes. But we need to be very clear about how the applicable case is recognized. It is certain means of using SIPS that will provide this guarantee. Other usages of sips may not. I don't think it is yet clear exactly what those usages are, and that is part of the task. > 1. SIPS requires the usage of TLS at every hop - none of this weasel > words on IPSec I'm still on the fence on this one. IPSec has its uses, and people using it will want some guarantees of secure communication too. I don't have an answer here, but I fear if we don't accommodate it explicitly then people will just cheat. > 2. there is no upgrading or downgrading, period I think this depends on what you mean by upgrading and downgrading. Below you propose that the home proxy can take a single registered contact and convert it from sip to sips or visa versa depending on how the call reached the AOR. That seems like upgrading or downgrading to me. Also, I don't want to have to independently register to the sip and sips form of my AOR, and yet I want calls to both forms to be valid. That also implies some form of upgrading or downgrading somewhere. I think it is more a matter of in what circumstances an AOR may be upgraded or downgraded. It must be restricted to cases where it remains clear whether there is a secure path end to end. So, it should be ok for the originator of a request to upgrade (and maybe to downgrade), but it isn't ok for others along the path to *that* target to do so. Once it reaches that target (the AOR), then some other rules cut it. Since upgrading or downgrading along the path is a translation, it is already forbidden by 3261, so this perhaps only amounts to a clarification. B2BUAs may (as always) present a special concern. As a UA, it may be valid for one to upgrade or downgrade. But that may be very deceptive to the ultimate target. So this may require some special specifications. > With these two rules, it becomes much clear what kind of benefits are > provided by sips. Every hop is secure with TLS, period. There remains the problem that this is hop by hop, and any of those hops can lie. So the guarantee is always conditional. Paul > No ifs, ands or > buts about it. If a UAS gets a request and the r-uri is sips, it means > every hop was TLS. If it gets a request and the r-uri is sip, there is > no guarantee about whether the hops were secure (they may or may not > have been). > > It also helps clarify the distinction between sips and transport=tls. > Namely, transport=tls just means that a particular hop uses TLS. It > implies nothing about the security of links upstream or downstream to > it. sips, however, implies that every single hop towards the resource > was secure. > > Moving on to some of the details, I think we can simplify the > registration procedure further. I would propose that it is never > necessary to include separate contacts for sip and sips. If a > registration is sent such that each hop was over TLS (done by having the > r-uri in the registration be a sips URI), then that contact (and the > associated secure path URI) can be used for requests sent to sip or sips > AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a > sips version of the contact. If a request is sent to a SIP AOR, the > r-uri is a sip version of the contact. > > Thoughts? > > -Jonathan R. > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 17 10:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFa-0006dn-6K; Wed, 17 May 2006 10:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNFY-0006dd-EZ for sip@ietf.org; Wed, 17 May 2006 10:43:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMRq-0001wy-MB for sip@ietf.org; Wed, 17 May 2006 09:52:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgMKr-0005Dn-LP for sip@ietf.org; Wed, 17 May 2006 09:45:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 May 2006 06:45:09 -0700 X-IronPort-AV: i="4.05,137,1146466800"; d="scan'208"; a="278246927:sNHT33123868" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4HDj8kh021152; Wed, 17 May 2006 06:45:08 -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 k4HDj8Hc016174; Wed, 17 May 2006 06:45:08 -0700 (PDT) Received: from [10.1.31.152] (sjc-vpn4-900.cisco.com [10.21.83.131]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HDgan1016092; Wed, 17 May 2006 06:42:38 -0700 In-Reply-To: <446B2842.90903@cisco.com> References: <446A71D4.4090409@cisco.com> <0070CB41-9493-4BD4-856C-76686AA025E6@cisco.com> <446B2842.90903@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3171F384-A93B-48D8-A01E-458D8505AEF4@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 09:44:57 -0400 To: Michael Thomas X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-1.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1599; t=1147873509; x=1148737509; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:David=20R=20Oran=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Dn1L1CCXXqIQr6cuYWIcrgB9pc7g=3D; b=IVuziKqoxQ8XN5rrrheb5s3jthONNrWBl7Wy0GBay8oeOISnyGMB7TVCa3F04bQ/yZy1gBt/ mdcYAsIfxlvqiaVuo6rEJuZ8RaHXkBOzjjvMtz6g0e9gM13iRm9NMnHU; X-Spam-Score: -2.6 (--) 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 May 17, 2006, at 9:42 AM, Michael Thomas wrote: > David R Oran wrote: > >> >> On May 16, 2006, at 8:44 PM, Jonathan Rosenberg wrote: >> >>> I'd propose that, to be useful, sips has to do as it implies - >>> it means that each and every link from UAC to UAS was secure. >>> This means two things: >>> >>> 1. SIPS requires the usage of TLS at every hop - none of this >>> weasel words on IPSec >>> >> Uh, why? This contradicts what you said above, which was that >> "each and every link...was secure". If that in fact is the >> desired semantic, how can you argue that, for example, a direct >> UAC-UAS IPSEC tunnel using AES-256 and keys delivered by NSA >> agents is not secure, while a multi-hop TLS connection where each >> hop uses null-encryption cypher or 40-bit keys is secure? >> >> I'd have less problem with this if SIPS was redefined to mean >> "each hop used TLS" and said NOTHING about whether the end-to- >> end communication was secure or not. >> >> On the other hand, what would be more useful would in fact be an >> end- to-end assertion about what level of security the UAS can >> count on. > > > How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_ > about whether > the previous hop was TLS, how exactly can you detect that? Sips is > nothing > more than a request that good actors act good, and no amount of > shoe pounding > on podiums is going to elevate it to first class status. > I didn't say it was easy/possible to do. I said it would be more 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 Wed May 17 11:24:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqs-0007EO-FJ; Wed, 17 May 2006 11:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqq-0007Do-UL for sip@ietf.org; Wed, 17 May 2006 11:22:16 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNqo-0006uW-ML for sip@ietf.org; Wed, 17 May 2006 11:22:16 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc12) with SMTP id <20060517152204m120041rdhe>; Wed, 17 May 2006 15:22:04 +0000 Message-ID: <051501c679c5$a77ca5c0$6e087c0a@china.huawei.com> From: "Spencer Dawkins" To: "IETF SIP List" References: <446A71D4.4090409@cisco.com> <446B3696.4070408@cisco.com> Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 10:22:04 -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.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 operative word here is "people"... >> 1. SIPS requires the usage of TLS at every hop - none of this weasel >> words on IPSec > > I'm still on the fence on this one. IPSec has its uses, and people using > it will want some guarantees of secure communication too. I don't have an > answer here, but I fear if we don't accommodate it explicitly then people > will just cheat. The problem is, using the APIs I'm familiar with, there's no indication that IPsec was used, when you get to the application level, so there's no reasonable way for applications to provide indications that communication was secure, without digging through kernel data structures. I'm finding this somewhat frustrating - as Dave pointed out, even saying "TLS" doesn't say anything about "secure" (see null encryption transform), much less "secure at every hop", but most people who care about security also care about confidentiality, including confidentiality at every hop. Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 17 11:40:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgO6O-0006a1-Is; Wed, 17 May 2006 11:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgO6M-0006Zq-Us for sip@ietf.org; Wed, 17 May 2006 11:38:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgO6K-000856-HS for sip@ietf.org; Wed, 17 May 2006 11:38:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 17 May 2006 08:38:16 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="1807896602:sNHT90049128" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4HFcFuW019136; Wed, 17 May 2006 08:38: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 k4HFcFHc000904; Wed, 17 May 2006 08:38:15 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn-hwcore-307.cisco.com [10.21.153.51]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HFZiOS018581; Wed, 17 May 2006 08:35:45 -0700 Message-ID: <446B4367.9000408@cisco.com> Date: Wed, 17 May 2006 08:38: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: Spencer Dawkins Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines References: <446A71D4.4090409@cisco.com> <446B3696.4070408@cisco.com> <051501c679c5$a77ca5c0$6e087c0a@china.huawei.com> In-Reply-To: <051501c679c5$a77ca5c0$6e087c0a@china.huawei.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=1778; t=1147880295; x=1148744295; c=relaxed/simple; s=sjdkim4001; 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]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3Ds8zUC0Q9SWMTMp3DguG5z6igkVQ=3D; b=dFXmgJLJLv/E6gO1UyqbOS7UtPy1KQbR988tktBs5l5WdyKlkH9FBwAKANQtolXz31a0NsHy C2LyO/tMJc83BCGh2lu0WklBQn/HJMHS68m4MUBTj0RRctDU5M8ZMzLb; 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Spencer Dawkins wrote: > I think the operative word here is "people"... > >>> 1. SIPS requires the usage of TLS at every hop - none of this weasel >>> words on IPSec >> >> >> I'm still on the fence on this one. IPSec has its uses, and people >> using it will want some guarantees of secure communication too. I >> don't have an answer here, but I fear if we don't accommodate it >> explicitly then people will just cheat. > > > The problem is, using the APIs I'm familiar with, there's no > indication that IPsec was used, when you get to the application level, > so there's no reasonable way for applications to provide indications > that communication was secure, without digging through kernel data > structures. > > I'm finding this somewhat frustrating - as Dave pointed out, even > saying "TLS" doesn't say anything about "secure" (see null encryption > transform), much less "secure at every hop", but most people who care > about security also care about confidentiality, including > confidentiality at every hop. Since SIPS is completely based on the good will of the participants, if you're going to have it at all it makes as much sense to include ipsec and probably SIP over Brinks Armored Car while we're at it. It doesn't require that the proxy be able to know that there's an actual SA active -- this could be just provisioned -- because ultimately the UAS has no way to know if somebody is fibbing anyway. Like I said earlier: SIPS is a *request* that good actors behave good; advertising it as anything else is overselling what SIPS actually gives you. In fact, I'd go so far as to say: a UAS MUST NOT take different action based upon whether an incoming request was labeled SIP or SIPS. 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 Wed May 17 12:29:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOrH-000304-8h; Wed, 17 May 2006 12:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOrF-0002tH-CV for sip@ietf.org; Wed, 17 May 2006 12:26:45 -0400 Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOrD-0001Cj-1a for sip@ietf.org; Wed, 17 May 2006 12:26:45 -0400 Received: from smtpftw3.verizon.com (smtpftw3.verizon.com [138.83.140.92]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id k4HGQsHB011129 for ; Wed, 17 May 2006 11:26:54 -0500 (EST) Received: from ftwp1cvmma03.vzh.ent.verizon.com (ftwp1cvmma03.verizon.com [138.83.138.145]) by smtpftw3.verizon.com (8.13.3/8.13.3) with ESMTP id k4HGQfIp015315 for ; Wed, 17 May 2006 12:26:41 -0400 (EDT) Received: from 138.83.34.48 by ftwp1cvmma03.vzh.ent.verizon.com with ESMTP (SMTP Relay); Wed, 17 May 2006 12:04:12 -0400 X-Server-Uuid: A685BAD7-0957-4BC4-A51C-E5E584A23F8F Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate2.verizon.com (8.13.3/8.13.3) with ESMTP id k4HG3UDt022932 for ; Wed, 17 May 2006 11:03:49 -0500 ( CDT) From: nabeel.2.cocker@verizon.com To: sip@ietf.org Message-ID: Date: Wed, 17 May 2006 12:03:46 -0400 X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 05/17/2006 11:03:48 MIME-Version: 1.0 X-WSS-ID: 687596E239G191371-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Nabeel 2. Cocker/EMPL/NY/Bell-Atl 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 05/17/2006 and will not return until 05/22/2006. I will respond to your message when I return. Regards, Nabeel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 17 14:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQwn-00078c-9w; Wed, 17 May 2006 14:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQwm-00078X-DB for sip@ietf.org; Wed, 17 May 2006 14:40:36 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQwl-0000gR-58 for sip@ietf.org; Wed, 17 May 2006 14:40:36 -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 k4HIeVI14534; Wed, 17 May 2006 14:40:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 13:40:29 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C22D34B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines Thread-Index: AcZ5tRlweD0JJ5iqRxK9TygM4q2c+gAKGKBQ From: "Samir Srivastava" To: "David R Oran" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 On the other hand, what would be more useful would in fact be an end- to-end assertion about what level of security the UAS can count on. SS>> I am working on a proposal where UAC states what cipher suites it needs in the path with the qValues in a header. UAC puts required cipher-suites with Proxy-Require and Require option tags. If the UAC desired level of security is not provided in the path, request is rejected by the proxy which is reached with the desired level of security. UAC can decide what to do if desired level of security is not provided end to end. It proposes to include the ciphersuites in the via header too for the UAS Knowledge.=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 Wed May 17 15:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgS21-0000B6-Qd; Wed, 17 May 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgS20-00009w-Lb; Wed, 17 May 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgS1y-0004Ov-BD; Wed, 17 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4HJo2et019181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgS1y-0002Ar-4s; Wed, 17 May 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, 17 May 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-flows-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 : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-sec-flows-00.txt Pages : 45 Date : 2006-5-17 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-flows-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-sec-flows-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-sec-flows-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-5-17105845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sec-flows-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sec-flows-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-17105845.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 May 17 16:56:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgT1L-0003tg-Cn; Wed, 17 May 2006 16:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgT1J-0003tO-Qy for sip@ietf.org; Wed, 17 May 2006 16:53:25 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgT1G-0001Qh-GV for sip@ietf.org; Wed, 17 May 2006 16:53:25 -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 k4HKrKI12834 for ; Wed, 17 May 2006 16:53:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 May 2006 15:53:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAc6OXQ From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] draft-audet-sip-sips-guidelines: Meaning of 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 I will break out the various topics regarding this draft into threads,=20 in order to facilite resolution. This thread is on the meaning of sips. Johnathan proposed the following: 1. SIPS requires the usage of TLS at every hop - none of this weasel=20 words on IPSec 2. there is no upgrading or downgrading, period Personally, I agree with point 1. As pointed out by others, it doesn't=20 necessarily mean it's more or less secure than IPsec (or whatever): it would just mean that TLS is to be used hop-by-hop, end-to-end. Period. The problem with the current weasel-words about IPsec in RFC3261 is that it makes it almost impossible to anybody to figure out what it means. At least "sips =3D=3D tls required on all hops" is something very concrete. Before we agree to this, it might be good to hear the point of view of some 3GPP folks. As for point 2, as pointed out by Paul, this is more complicated. Upgrading/ Downgrading means different things depending if we are talking R-URI or Contact or AOR. Personally, I would agree that upgrading/dowgrading in a R-URI should be banned. (I think this is what Johnathan meant). Futher points made by Johnathan regarding Registration in fact were pointing to quasi mandating upgrading/downgrating when talking about contacts and AOR.=20 I want to defer that particular discussion to another thread that I'll start=20 soon. So..... Can we agree on the following: 1. SIPS in a R-URI requires the usage of TLS at every hop - none of this weasel=20 words on IPSec 2. there is no upgrading or downgrading of R-URIs, period PS: If we don't get a mailing group consensus, I'll just mark it as Open Issue on the next version of the 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 May 17 17:05:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTBC-0006jb-SP; Wed, 17 May 2006 17:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTBC-0006jW-6r for sip@ietf.org; Wed, 17 May 2006 17:03:38 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTB9-00021g-VJ for sip@ietf.org; Wed, 17 May 2006 17:03:38 -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 k4HL3Ov25636; Wed, 17 May 2006 17:03:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 May 2006 16:02:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09B97C91@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines: usage of transport=tls Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAdXIkg From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 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 point made by Jonathan is that transport=3Dtls would mean=20 just a particular hop, not end-to-end (like sips). I have received the same comments from others. Personally, I'm not sure why this is needed. I think that it could be deprecated entirely (which was my interpretation of RFC 3261). That role in my mind is already=20 fullfilled by the Via header. That would take care of the contact URI. I'm not opposed to keeping it, but I just can't understand where it actually=20 helps.=20 If we DO decide to keep it, then, we also need to add a tls-sctp (as was done for the Via field already). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 17 17:18:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTNg-0006K1-DT; Wed, 17 May 2006 17:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTNf-0006Em-90 for sip@ietf.org; Wed, 17 May 2006 17:16:31 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTNf-0002mp-14 for sip@ietf.org; Wed, 17 May 2006 17:16:31 -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 k4HLGSI20772; Wed, 17 May 2006 17:16:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 May 2006 16:16:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAdskEw From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations X-BeenThere: sip@ietf.org X-Mailman-Version: 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 made a proposal that Contacts in registrations be automatically "upgradable/downgradable" between sip and sips.=20 His exact wording: > I would propose that it is never=20 > necessary to include separate contacts for sip and sips. If a=20 > registration is sent such that each hop was over TLS (done by=20 > having the=20 > r-uri in the registration be a sips URI), then that contact (and the=20 > associated secure path URI) can be used for requests sent to=20 > sip or sips=20 > AOR. If a request is sent to a SIPS AOR, the proxy sets the=20 > r-uri to a=20 > sips version of the contact. If a request is sent to a SIP AOR, the=20 > r-uri is a sip version of the contact. The draft I wrote actually takes the opposite approach. It proposes that the UA always explicitely registers sip and sips contacts (in the same registration) in order to bind each one to the AOR. The AOR itself=20 however is "upgradable/downgradable" the same way Jonathan is saying. It has the advantage that a UA can then specifically request to be reachable ONLY using a sips contact, ONLY using a sip contact, or BOTH (and also specify q-value). It also allows to explicitely say if it is reachable with UDP (again, with a q-value). This could be very useful for a UA that has a policy of "always TLS, never TLS, either (TLS prefered), or either (non-TLS prefered). I don't think this is easily achievable with Jonathan's proposal. Other 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 May 17 17:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTgE-0005o5-LJ; Wed, 17 May 2006 17:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgTgC-0005o0-Ut for sip@ietf.org; Wed, 17 May 2006 17:35:40 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgTgC-0004NB-9q for sip@ietf.org; Wed, 17 May 2006 17:35:40 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 18 May 2006 03:22:07 -0700 X-IronPort-AV: i="4.05,138,1146466800"; d="scan'208"; a="67920611:sNHT30721900" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4HLXdDs027833; Thu, 18 May 2006 05:33:40 +0800 (CST) Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 05:35:35 +0800 Received: from [10.70.230.89] ([10.70.230.89]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 05:35:34 +0800 Message-ID: <446B9723.6040206@cisco.com> Date: Wed, 17 May 2006 17:35:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 21:35:34.0882 (UTC) FILETIME=[D4B0EC20:01C679F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: > I will break out the various topics regarding this draft into threads, > in order to facilite resolution. > > This thread is on the meaning of sips. > > Johnathan proposed the following: > > 1. SIPS requires the usage of TLS at every hop - none of this weasel > words on IPSec > > 2. there is no upgrading or downgrading, period > > > Personally, I agree with point 1. As pointed out by others, it doesn't > necessarily mean it's more or less secure than IPsec (or whatever): it > would > just mean that TLS is to be used hop-by-hop, end-to-end. Period. > > The problem with the current weasel-words about IPsec in RFC3261 is that > > it makes it almost impossible to anybody to figure out what it means. At > least "sips == tls required on all hops" is something very concrete. > > Before we agree to this, it might be good to hear the point of view of > some > 3GPP folks. > > As for point 2, as pointed out by Paul, this is more complicated. > Upgrading/ > Downgrading means different things depending if we are talking R-URI or > Contact or AOR. > > Personally, I would agree that upgrading/dowgrading in a R-URI should be > banned. (I think this is what Johnathan meant). I think this still needs more clarification of what it means. How about the following: If the R-URI of a message contains a SIPS URI, then it MAY be replaced with some other SIPS URI (when allowed by the rules of 3261) but MUST NOT be replaced with a URI having any other scheme, even if otherwise allowed by 3261. > Futher points made by Johnathan regarding Registration in fact were > pointing > to quasi mandating upgrading/downgrating when talking about contacts and > AOR. > I want to defer that particular discussion to another thread that I'll > start > soon. > > So..... > > Can we agree on the following: > > 1. SIPS in a R-URI requires the usage of TLS at every hop - none of this > weasel > words on IPSec I'm not ready to agree with this. I am expecially persuaded by Dave O and others that knowing SIPS is in use end to end doesn't actually guarantee anything about the security properties of the session, even if you do trust all the intervening hops. Clarifying the meaning of SIPS does no good if the result is that the meaning is "nothing". I guess if we know every hop uses SIPS, it means that we transitively know that the callee has been verified to be who he claims to be, whoever that is. Is that enough? I thought that security of the session is an essential property of SIPS - that if I use SIPS I can then safely do something like exchange media keys using sdescriptions. If that is a goal, then we need to find a way for use of SIPS to provide that guarantee. That may or may not require use of TLS at every hop. > 2. there is no upgrading or downgrading of R-URIs, period I'm ok with the interpretation of this I gave above. Paul > PS: If we don't get a mailing group consensus, I'll just mark it as Open > Issue > on the next version of the 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 Wed May 17 18:14:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUF5-00032K-Ox; Wed, 17 May 2006 18:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUF3-000323-TG for sip@ietf.org; Wed, 17 May 2006 18:11:41 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUF3-0006QD-BS for sip@ietf.org; Wed, 17 May 2006 18:11:41 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 18 May 2006 03:58:09 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="67921491:sNHT29436248" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4HM9eDs029062; Thu, 18 May 2006 06:09:41 +0800 (CST) Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 06:11:36 +0800 Received: from [10.70.230.89] ([10.70.230.89]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 06:11:35 +0800 Message-ID: <446B9F94.90609@cisco.com> Date: Wed, 17 May 2006 18:11:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations References: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 22:11:35.0978 (UTC) FILETIME=[DCCE00A0:01C679FE] 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 Audet wrote: > Jonathan made a proposal that Contacts in registrations be automatically > "upgradable/downgradable" between sip and sips. > > His exact wording: >> I would propose that it is never >> necessary to include separate contacts for sip and sips. If a >> registration is sent such that each hop was over TLS (done by >> having the >> r-uri in the registration be a sips URI), then that contact (and the >> associated secure path URI) can be used for requests sent to >> sip or sips >> AOR. If a request is sent to a SIPS AOR, the proxy sets the >> r-uri to a >> sips version of the contact. If a request is sent to a SIP AOR, the >> r-uri is a sip version of the contact. > > The draft I wrote actually takes the opposite approach. > > It proposes that the UA always explicitely registers sip and sips > contacts > (in the same registration) in order to bind each one to the AOR. The AOR > itself > however is "upgradable/downgradable" the same way Jonathan is saying. > > It has the advantage that a UA can then specifically request to be > reachable > ONLY using a sips contact, ONLY using a sip contact, or BOTH (and > also specify q-value). It also allows to explicitely say if it is > reachable > with UDP (again, with a q-value). This could be very useful for a UA > that has > a policy of "always TLS, never TLS, either (TLS prefered), or either > (non-TLS > prefered). I don't think this is easily achievable with Jonathan's > proposal. > > Other comments? I don't much like having to register multiple contacts. But in practice I doubt anyone will do so anyway. In practice I think a UA that supports SIPS will need -outbound- for the TLS connection (because it probably doesn't have a cert), so that connection will be present. There will then be little reason to have another path. So I don't find your proposal too burdensome. A problem with Jonathan's proposal, and actually any proposal that upgrades or downgrades the scheme in a URI, is that it interacts poorly with a transport= uri parameter. I might want to use TLS for both SIP and SIPS calls. Or I conceivably might want to allow UDP for SIP calls, while using TLS for SIPS calls. (I'm not sure that actually makes much sense.) So I think I prefer Francois' version better, but I think Jonathan's could be tweaked to be fine. And I think the rules for upgrade/downgrade must be refined to take account of the transport parameter, and possibly other parameters. (maddr?) 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 May 17 18:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUTN-0001wP-BL; Wed, 17 May 2006 18:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUTL-0001t6-FF for sip@ietf.org; Wed, 17 May 2006 18:26:27 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUTK-00070l-7A for sip@ietf.org; Wed, 17 May 2006 18:26:27 -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.4) with ESMTP id k4HMQNIV080375 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 17 May 2006 17:26:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44DFFB16-7083-4E5F-87D7-3486DB17C027@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Wed, 17 May 2006 17:26:22 -0500 To: sip@ietf.org X-Mailer: Apple Mail (2.749.3) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Keith Drage , Dean Willis Subject: [Sip] Building a "feature list" for interop statements X-BeenThere: sip@ietf.org X-Mailman-Version: 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 IETF65 we discussed starting to build the feature list we'd use for the interoperability statements used in eventually advancing the core SIP standards. I'd like to reissue the call for volunteers I made at that time. If you have the time and interest to help with a divide-and-conquer approach to building this list, send me email. I'll work with the chairs to pull together a team out of the volunteers targeting a first draft before IETF66. Respond quickly - I'd like to set up the first meeting of this team by the middle of next week. To say this is a non-trivial effort is a gross understatement. Please volunteer only if you really can give this real time between now and the Montreal meeting. So far, its just me and Jonathan... 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 Wed May 17 18:30:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUVT-00032s-Tf; Wed, 17 May 2006 18:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUVS-00032n-Q0 for sip@ietf.org; Wed, 17 May 2006 18:28:38 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUVR-00074o-Eq for sip@ietf.org; Wed, 17 May 2006 18:28:38 -0400 Received: from [192.168.1.4] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4HMTgAY032607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 17 May 2006 17:29:45 -0500 In-Reply-To: <446A71D4.4090409@cisco.com> References: <446A71D4.4090409@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15C5157D-1A28-48CD-8FDB-384E924D5FBE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 17 May 2006 17:28:31 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) 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 On May 16, 2006, at 7:44 PM, Jonathan Rosenberg wrote: > > I'd propose that, to be useful, sips has to do as it implies - it > means that each and every link from UAC to UAS was secure. This > means two things: > > 1. SIPS requires the usage of TLS at every hop - none of this > weasel words on IPSec > > 2. there is no upgrading or downgrading, period > So, how do you KNOW that TLS was actually used at each hop? Until you have a way to KNOW that it was, all you have is a vague hope that the serving proxy to UA link was secured properly, and no amount of "MUST" in the specification is going to change it. You'll have added feel-good words to the specification that don't actually improve the security characteristics. Not only that, but you will have prevented "real deployable security" where some links -- like UA to serving proxy -- are actually secured by something like IMS-IPSEC. Net result, everybody will just use sip:, and the security situation will actually degrade relative to where it is today (where sips: works at least part of the time). TLS works with HTTP because it works end-to-end, tunneling through the HTTP proxies. If a proxy cheats and acts like a B2BUA for TLS, the client can check the cert-name and detect the misbehavior. But with sips:, we have no way for the UAC to "check up" on the proxies. For sips: to give the kind of security assurance you seem to want, it has to work end-to-end "through" the proxies, like https: does. -- 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 May 17 18:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUbl-0004rJ-MR; Wed, 17 May 2006 18:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUbk-0004rE-Rv for sip@ietf.org; Wed, 17 May 2006 18:35:08 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUbk-0007OX-Hv for sip@ietf.org; Wed, 17 May 2006 18:35:08 -0400 Received: from [192.168.1.4] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4HMaDMo032651 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 17 May 2006 17:36:15 -0500 In-Reply-To: <446B9723.6040206@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> <446B9723.6040206@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F00B384-69ED-4F36-93D5-75CBAD3E7B8A@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 17 May 2006 17:35:02 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 May 17, 2006, at 4:35 PM, Paul Kyzivat wrote: > > I guess if we know every hop uses SIPS, it means that we > transitively know that the callee has been verified to be who he > claims to be, whoever that is. Is that enough? > Nope. can't make that assertion. A UAC can establish single-ended TLS to a server that might not bother to do secondary authentication, but still be completely requirement with "TLS was used at every hop". > I thought that security of the session is an essential property of > SIPS - that if I use SIPS I can then safely do something like > exchange media keys using sdescriptions. If that is a goal, then we > need to find a way for use of SIPS to provide that guarantee. That > may or may not require use of TLS at every hop. If the sdescriptions are revealed to every intervening proxy, I don't think you have much in the way of security. A proxy can be identifiable (via TLS assertion) without being trustworthy. -- 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 May 17 18:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUgE-0007yZ-5O; Wed, 17 May 2006 18:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUgC-0007yM-H6 for sip@ietf.org; Wed, 17 May 2006 18:39:44 -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 1FgUgA-0007og-7m for sip@ietf.org; Wed, 17 May 2006 18:39:44 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 17 May 2006 15:39:42 -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/8.12.11) with ESMTP id k4HMdfiP001339; Wed, 17 May 2006 15:39:41 -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 k4HMdfB9027932; Wed, 17 May 2006 15:39:41 -0700 (PDT) Received: from [171.71.193.207] (dhcp-171-71-193-207.cisco.com [171.71.193.207]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4HMbAxX027904; Wed, 17 May 2006 15:37:11 -0700 Message-ID: <446BA62F.6010401@cisco.com> Date: Wed, 17 May 2006 15:39:43 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> <446B9723.6040206@cisco.com> <0F00B384-69ED-4F36-93D5-75CBAD3E7B8A@softarmor.com> In-Reply-To: <0F00B384-69ED-4F36-93D5-75CBAD3E7B8A@softarmor.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=1275; t=1147905581; x=1148769581; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DyzsSCxLWm96E0P7v4EIroZxlUvU=3D; b=GyTGFYEqe5b5Lrd/zfLO82KpICOLqT3kGr2H+FqEFQHO+xL2X4FcBPb7isL92db7OYLPWg47 s9HJ/R9aHiGaivIfBrTb9rv9v7ze7bkc10S+cJwgLNy/z8qanF6jBNT+; X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , Paul Kyzivat , 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 Dean Willis wrote: > > On May 17, 2006, at 4:35 PM, Paul Kyzivat wrote: > >> >> I guess if we know every hop uses SIPS, it means that we >> transitively know that the callee has been verified to be who he >> claims to be, whoever that is. Is that enough? >> > > Nope. can't make that assertion. A UAC can establish single-ended TLS > to a server that might not bother to do secondary authentication, but > still be completely requirement with "TLS was used at every hop". > > >> I thought that security of the session is an essential property of >> SIPS - that if I use SIPS I can then safely do something like >> exchange media keys using sdescriptions. If that is a goal, then we >> need to find a way for use of SIPS to provide that guarantee. That >> may or may not require use of TLS at every hop. > > > If the sdescriptions are revealed to every intervening proxy, I don't > think you have much in the way of security. A proxy can be > identifiable (via TLS assertion) without being trustworthy. Right. I've had my suspicions about SIPS for a long while, and if Paul's interpretation is common, then I'd say that SIPS is actually harmful. Mike, even though as a Please Do This mechanism it has utility. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 17 18:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUqd-0004IU-IA; Wed, 17 May 2006 18:50:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUqb-0004Fp-6r for sip@ietf.org; Wed, 17 May 2006 18:50:29 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgUqZ-0008Tg-TK for sip@ietf.org; Wed, 17 May 2006 18:50:29 -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 k4HMjNW16211; Wed, 17 May 2006 18:45:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 17 May 2006 17:50:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ6AimVRZEpBk7ISQ+JXj3kqQ6JZAAAcENA From: "Francois Audet" To: "Dean Willis" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Dean. To me, using sips in Req-URI tells proxies forward the request on every hop using TLS. Receiving sips actually doesn't really tell you much, and you certainly can't extrapolate that "the call was secure". > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Wednesday, May 17, 2006 15:35 > To: Paul Kyzivat > Cc: Audet, Francois [SC100:3055:EXCH]; IETF SIP List > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 >=20 > On May 17, 2006, at 4:35 PM, Paul Kyzivat wrote: >=20 > > > > I guess if we know every hop uses SIPS, it means that we > > transitively know that the callee has been verified to be who he =20 > > claims to be, whoever that is. Is that enough? > > >=20 > Nope. can't make that assertion. A UAC can establish=20 > single-ended TLS =20 > to a server that might not bother to do secondary=20 > authentication, but =20 > still be completely requirement with "TLS was used at every hop". >=20 >=20 > > I thought that security of the session is an essential property of > > SIPS - that if I use SIPS I can then safely do something like =20 > > exchange media keys using sdescriptions. If that is a goal,=20 > then we =20 > > need to find a way for use of SIPS to provide that guarantee. That =20 > > may or may not require use of TLS at every hop. >=20 > If the sdescriptions are revealed to every intervening proxy,=20 > I don't =20 > think you have much in the way of security. A proxy can be =20 > identifiable (via TLS assertion) without being trustworthy. >=20 > -- > Dean >=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 May 17 19:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVGf-0004Pg-Az; Wed, 17 May 2006 19:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBAV-0000l9-Qt for sip@ietf.org; Mon, 08 May 2006 15:13:19 -0400 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBAR-0002Cb-Df for sip@ietf.org; Mon, 08 May 2006 15:13:19 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 12:13:15 -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 k48JDEw1019366 for ; Mon, 8 May 2006 12:13:14 -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, 8 May 2006 12:13:14 -0700 Received: from caryfitz-mac.local ([10.32.130.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 12:13:14 -0700 Received: by caryfitz-mac.local (Postfix, from userid 501) id 9A6F3193295; Mon, 8 May 2006 12:13:14 -0700 (PDT) Date: Mon, 8 May 2006 12:13:14 -0700 (PDT) From: Cary FitzGerald X-X-Sender: caryfitz@caryfitz-mac.local To: Jonathan Rosenberg Subject: Re: [Sip] ISSUE 1 in Hitchhikers guide to SIP: Whats in, whats out In-Reply-To: <445F92D9.6000807@cisco.com> Message-ID: References: <445F92D9.6000807@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 May 2006 19:13:14.0468 (UTC) FILETIME=[747D6A40:01C672D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Wed, 17 May 2006 19:17:19 -0400 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 it depends on the goal of the document. As the size of the community of interest around SIP/VoIP has grown, and as the complexity of SIP has grown, this document fills an important need of identifying what an aspiring member of the community should know in order to understand the field. Given that both of these topics have been the subject of considerable dialog on the various mailing lists, my inclination is to include them. Cary. On Mon, 8 May 2006, Jonathan Rosenberg wrote: > In preparing to revise the hitchhikers guide to sip (currently at: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchhikers-guide-00.txt), > there are a few open issues it would be good to try and resolve. I'm going to > send out a few notes to try and do that. > > The first and biggest one is around what documents are in scope to be covered > by this specification, and which are not. During the meeting, folks pointed > out that the absence of SDP and RFC 3264 seemed wrong, and Henry suggested > that ICE be included too. The criteria I had defined for this document was > that something had to be a literal SIP extension to be included. I think the > feedback is that this is too narrow of a definition. Spencer had also > commented that MIME objects defined for SIP (like AIB) shouldn't be exlcuded > either (they are not SIP extensions). > > So, I would offer up the following as a proposed scope for inclusion of a > document: > > * Specifies an IETF approved extension to SIP itself > * Specifies an IETF approved extension to SDP whose primary purpose is to > support SIP > * Specifies a MIME object whose primary purpose is to support SIP > > This would, consequently, expand the scope of the hitchhikers guide to the > many SDP extensions. I think thats OK, but folks should be aware of that. > > Comments or alternatives? > > 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 Wed May 17 19:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVVr-0004rt-0G; Wed, 17 May 2006 19:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVVq-0004ro-3V for sip@ietf.org; Wed, 17 May 2006 19:33:06 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVVo-0002Lh-Ia for sip@ietf.org; Wed, 17 May 2006 19:33:06 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 18 May 2006 05:19:32 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="67923924:sNHT30941696" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4HNUvDu002960; Thu, 18 May 2006 07:31:03 +0800 (CST) Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 07:32:52 +0800 Received: from [10.70.230.89] ([10.70.230.89]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 May 2006 07:32:52 +0800 Message-ID: <446BB2A1.8080700@cisco.com> Date: Wed, 17 May 2006 19:32:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 23:32:52.0578 (UTC) FILETIME=[377C1C20:01C67A0A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Based on what I am hearing, it seem like the best course might be to deprecate SIPS and begin work on something else that provides some useful security properties. Paul Francois Audet wrote: > I agree with Dean. > > To me, using sips in Req-URI tells proxies forward the request on every > hop using TLS. > > Receiving sips actually doesn't really tell you much, and you certainly > can't > extrapolate that "the call was secure". > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Wednesday, May 17, 2006 15:35 >> To: Paul Kyzivat >> Cc: Audet, Francois [SC100:3055:EXCH]; IETF SIP List >> Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >> >> >> >> On May 17, 2006, at 4:35 PM, Paul Kyzivat wrote: >> >>> I guess if we know every hop uses SIPS, it means that we >>> transitively know that the callee has been verified to be who he >>> claims to be, whoever that is. Is that enough? >>> >> Nope. can't make that assertion. A UAC can establish >> single-ended TLS >> to a server that might not bother to do secondary >> authentication, but >> still be completely requirement with "TLS was used at every hop". >> >> >>> I thought that security of the session is an essential property of >>> SIPS - that if I use SIPS I can then safely do something like >>> exchange media keys using sdescriptions. If that is a goal, >> then we >>> need to find a way for use of SIPS to provide that guarantee. That >>> may or may not require use of TLS at every hop. >> If the sdescriptions are revealed to every intervening proxy, >> I don't >> think you have much in the way of security. A proxy can be >> identifiable (via TLS assertion) without being trustworthy. >> >> -- >> 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 May 17 19:40:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVaw-0007rC-6p; Wed, 17 May 2006 19:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfuVs-0003WT-H7 for sip@ietf.org; Tue, 16 May 2006 04:02:40 -0400 Received: from web53108.mail.yahoo.com ([206.190.49.58]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfuVq-0007B7-2l for sip@ietf.org; Tue, 16 May 2006 04:02:40 -0400 Received: (qmail 25061 invoked by uid 60001); 16 May 2006 08:00:09 -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=syhVmuINafSjU+bxMETsRZoN1G7MDt6QoIGpE0Tfm02uhO4BE8F/UtBLSlsYqhpQgaUXZ6tGEvGYNS52y3atXgjC+FmkTICjrnTbtIe3SjdqQqqErmkPySDE6VJQYSrXEvfjUP+H4SoltQJtk/cx1rdmTGBxVSm9c2NWWWXTh8Q= ; Message-ID: <20060516080007.24968.qmail@web53108.mail.yahoo.com> Received: from [212.117.81.29] by web53108.mail.yahoo.com via HTTP; Tue, 16 May 2006 01:00:06 PDT Date: Tue, 16 May 2006 01:00:06 -0700 (PDT) From: Bolt Vlatko To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 17 May 2006 19:38:21 -0400 Subject: [Sip] SIP bug 760 - Can multiple transports be tried on a single DNS lookup? X-BeenThere: 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="===============0548017529==" Errors-To: sip-bounces@ietf.org --===============0548017529== Content-Type: multipart/alternative; boundary="0-215658963-1147766406=:95688" Content-Transfer-Encoding: 8bit --0-215658963-1147766406=:95688 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bug 760 in SIP working group, http://bugs.sipit.net/show_bug.cgi?id=760, clarifies that reattempts in case of failures should be limited only to one transport determined by 3263/NAPTR procesing. It still has status NEW (it hasn't been resolved yet). Is this well known, recognized fault that should be avoided in implementation of RFC 3263 in SIP products or there are different opinions in SIP working group? Thanks in advance. BR, Vlatko --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. --0-215658963-1147766406=:95688 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Bug 760 in SIP working group, http://bugs.sipit.net/show_bug.cgi?id=760, clarifies that reattempts in case of failures should be limited only to one transport determined by 3263/NAPTR procesing.
It still has status NEW (it hasn't been resolved yet).
Is this well known, recognized fault that should be avoided in implementation of RFC 3263 in SIP products or there are different opinions in SIP working
group?
 
Thanks in advance.
 
BR, Vlatko

Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. --0-215658963-1147766406=:95688-- --===============0548017529== 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 --===============0548017529==-- From sip-bounces@ietf.org Wed May 17 20:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWNI-0003fJ-4g; Wed, 17 May 2006 20:28:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWNH-0003fE-GG for sip@ietf.org; Wed, 17 May 2006 20:28:19 -0400 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWNG-0005AP-8n for sip@ietf.org; Wed, 17 May 2006 20:28:19 -0400 Received: by nz-out-0102.google.com with SMTP id m22so188970nzf for ; Wed, 17 May 2006 17:28:17 -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=Az7PgIXip4WaXPAfecUJq7B5lK7Mzsuz4lqfY19wCPsjqZJSIV0EwIv4vIXVEozC4AsEittNxmhrgFU2iehATIShb2pGOhcrqgcd+0DsF0mimwdToVk7ETVzo47OYL9TzHlvayMt9IgoLbBBqR+cN3oHtIVjzG56EFN9DWiIr5g= Received: by 10.36.104.11 with SMTP id b11mr912408nzc; Wed, 17 May 2006 17:27:36 -0700 (PDT) Received: by 10.36.132.20 with HTTP; Wed, 17 May 2006 17:28:17 -0700 (PDT) Message-ID: <4ff4e7370605171728v5c037453u7c242193375db80@mail.gmail.com> Date: Wed, 17 May 2006 17:28:17 -0700 From: Venkatesh To: jdrosen@cisco.com, sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Sip] Resolution on reuse of payload types and RFC 3264. X-BeenThere: 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="===============1108270143==" Errors-To: sip-bounces@ietf.org --===============1108270143== Content-Type: multipart/alternative; boundary="----=_Part_4078_4385066.1147912097346" ------=_Part_4078_4385066.1147912097346 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi: Per section 8.3.2 of RFC 3264, dynamic payload types are fixed for a sessio= n and MUST NOT change for the duration of the session. This requirement leads to problems when you have B2BUA's in the picture. I was looking at bugzilla and I found the issues with this requirement outlined in http://bugs.sipit.net/show_bug.cgi?id=3D739. The bug goes on to say the fi= x should be to relax this requirement. I wanted to know if there was any fina= l agreement on the same and if yes, what the final resolution was? Any pointers will be helpful. Thanks Venkatesh ------=_Part_4078_4385066.1147912097346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi:
 
Per section 8.3.2 of RFC 3264, dynamic payload types are fixed for a s= ession and MUST NOT change for the duration of the session. This requiremen= t leads to problems when you have B2BUA's in the picture. I was looking at = bugzilla and I found the issues with this requirement outlined in=20 http://bugs.sipit.n= et/show_bug.cgi?id=3D739.  The bug goes on to say the fix should b= e to relax this requirement. I wanted to know if there was any final agreem= ent on the same and if yes, what the final resolution was? Any pointers wil= l be helpful.
 
Thanks
Venkatesh
------=_Part_4078_4385066.1147912097346-- --===============1108270143== 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 --===============1108270143==-- From sip-bounces@ietf.org Thu May 18 00:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgaXb-0001XR-FQ; Thu, 18 May 2006 00:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgaXZ-0001W3-Ln for sip@ietf.org; Thu, 18 May 2006 00:55:13 -0400 Received: from yass.opencloud.co.nz ([131.203.101.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgaXW-00042q-D6 for sip@ietf.org; Thu, 18 May 2006 00:55:13 -0400 Received: from tortilla.opencloud.co.nz ([192.168.0.37]) by yass.opencloud.co.nz with asmtp (TLS-1.0:DHE_RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1FgaXQ-0005E9-F4 for sip@ietf.org; Thu, 18 May 2006 16:55:04 +1200 Message-ID: <446BFE27.4070909@opencloud.com> Date: Thu, 18 May 2006 16:55:03 +1200 From: Ben Evans User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] draft-ietf-sip-outbound-03: proxy routing question X-BeenThere: sip@ietf.org X-Mailman-Version: 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 trying to figure out what should be a simple proxying scenario using draft-ietf-sip-outbound-03. Consider the following scenario: UA1 -------> proxy ------- UA2 flow 1. UA1 forms a flow to a proxy/registrar (no edge proxies involved) and registers successfully. 2. UA2 makes a call to UA1 (UA2 may or may not have a flow to the proxy, it does not matter here). 3. The proxy receives the INVITE, looks up UA1's AOR (the Request-URI) in its location service, and finds the contact URI and the flow information. The proxy then uses the flow to send the request to UA1. The proxy also adds itself to the Record-Route header. 4. UA1 responds with 200 OK, which is forwarded to UA2. 5. UA2 now has to send the ACK. It forms the ACK request using UA1's contact URI as the Request-URI, and the route set from the dialog. 6. The proxy receives the ACK from UA2... My problem is: how does the proxy know to send the ACK out on the correct flow to UA1?? Because the ACK's Request-URI contains UA1's contact URI, not the AOR, the proxy would normally not do a location service lookup (the contact URI is a physical IP address/port). So how does the proxy obtain the flow information from the location service so that it can send the ACK (and any future mid-dialog requests) on the correct flow? What am I missing? Thanks Ben -- Ben Evans / Software Engineer / Open Cloud / ben.evans@opencloud.com Tel: +6421636182 / PO Box 19210, Wellington, NZ / www.opencloud.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 May 18 02:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgblf-0003z1-4s; Thu, 18 May 2006 02:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgble-0003yt-7r for sip@ietf.org; Thu, 18 May 2006 02:13:50 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgbla-00009t-Lf for sip@ietf.org; Thu, 18 May 2006 02:13:50 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B51D81400C3; Thu, 18 May 2006 09:13:40 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 8287B13F98A; Thu, 18 May 2006 09:13:34 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 4E391F01E3; Thu, 18 May 2006 09:13:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4234.262207.613629@rautu.tutpro.com> Date: Thu, 18 May 2006 09:13:30 +0300 From: Juha Heinanen To: "Francois Audet" Subject: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97C91@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF09B97C91@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 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 Francois Audet writes: > I have received the same comments from others. Personally, I'm not sure > why this is needed. I think that it could be deprecated entirely (which > was my interpretation of RFC 3261). That role in my mind is already > fullfilled by the Via header. That would take care of the contact > URI. without transport=tls, how can you, for example, tell to your proxy to use tls to a particular PSTN gw? -- 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 May 18 02:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc2d-0001V9-Ly; Thu, 18 May 2006 02:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc1p-0000tq-9v for sip@ietf.org; Thu, 18 May 2006 02:30:33 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgbuA-0000a2-G2 for sip@ietf.org; Thu, 18 May 2006 02:22:39 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B81CB1400BA; Thu, 18 May 2006 09:22:37 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id F13ED1400B1; Thu, 18 May 2006 09:22:30 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D40C7F01E3; Thu, 18 May 2006 09:22:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4774.815740.621461@rautu.tutpro.com> Date: Thu, 18 May 2006 09:22:30 +0300 From: Juha Heinanen To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <446BA62F.6010401@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> <446B9723.6040206@cisco.com> <0F00B384-69ED-4F36-93D5-75CBAD3E7B8A@softarmor.com> <446BA62F.6010401@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 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 Michael Thomas writes: > Right. I've had my suspicions about SIPS for a long while, and if Paul's > interpretation is common, then I'd say that SIPS is actually > harmful. SIPS was added to rfc3261 at the very last minute without any implementation or even interpretation experience. because it doesn't give any end-to-end guarantees, i agree that it is useless. transport=tls, on the other hand, is useful and should be kept. -- 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 May 18 02:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc2R-0001Js-NW; Thu, 18 May 2006 02:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc1v-0000tq-Nq for sip@ietf.org; Thu, 18 May 2006 02:30:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgbnd-0000HQ-SP for sip@ietf.org; Thu, 18 May 2006 02:15:54 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 25BED1400C3; Thu, 18 May 2006 09:15:53 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP idFrom sip-bounces@ietf.org Thu May 18 02:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc2d-0001V9-Ly; Thu, 18 May 2006 02:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc1p-0000tq-9v for sip@ietf.org; Thu, 18 May 2006 02:30:33 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgbuA-0000a2-G2 for sip@ietf.org; Thu, 18 May 2006 02:22:39 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B81CB1400BA; Thu, 18 May 2006 09:22:37 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id F13ED1400B1; Thu, 18 May 2006 09:22:30 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D40C7F01E3; Thu, 18 May 2006 09:22:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4774.815740.621461@rautu.tutpro.com> Date: Thu, 18 May 2006 09:22:30 +0300 From: Juha Heinanen To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <446BA62F.6010401@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97C60@zrc2hxm0.corp.nortel.com> <446B9723.6040206@cisco.com> <0F00B384-69ED-4F36-93D5-75CBAD3E7B8A@softarmor.com> <446BA62F.6010401@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 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 Michael Thomas writes: > Right. I've had my suspicions about SIPS for a long while, and if Paul's > interpretation is common, then I'd say that SIPS is actually > harmful. SIPS was added to rfc3261 at the very last minute without any implementation or even interpretation experience. because it doesn't give any end-to-end guarantees, i agree that it is useless. transport=tls, on the other hand, is useful and should be kept. -- 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 May 18 02:33:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc2R-0001Js-NW; Thu, 18 May 2006 02:31:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc1v-0000tq-Nq for sip@ietf.org; Thu, 18 May 2006 02:30:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgbnd-0000HQ-SP for sip@ietf.org; Thu, 18 May 2006 02:15:54 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 25BED1400C3; Thu, 18 May 2006 09:15:53 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 064A913F98A; Thu, 18 May 2006 09:15:42 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 61FD7F01E3; Thu, 18 May 2006 09:15:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4365.347730.146698@rautu.tutpro.com> Date: Thu, 18 May 2006 09:15:41 +0300 From: Juha Heinanen To: "Francois Audet" Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 writes: > I don't think this is easily achievable with Jonathan's > proposal. if sip ua accepts both sip and sips, there is no problem. if it accepts only one, it will give negative reply if you try with the other. i don't see where the problem is. -- 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 064A913F98A; Thu, 18 May 2006 09:15:42 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 61FD7F01E3; Thu, 18 May 2006 09:15:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4365.347730.146698@rautu.tutpro.com> Date: Thu, 18 May 2006 09:15:41 +0300 From: Juha Heinanen To: "Francois Audet" Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 writes: > I don't think this is easily achievable with Jonathan's > proposal. if sip ua accepts both sip and sips, there is no problem. if it accepts only one, it will give negative reply if you try with the other. i don't see where the problem is. -- 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 May 18 02:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc9h-00039M-1h; Thu, 18 May 2006 02:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgc1o-0000tq-Vo for sip@ietf.org; Thu, 18 May 2006 02:30:32 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgbur-0000aN-Rc for sip@ietf.org; Thu, 18 May 2006 02:23:23 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 28DFF1400BA; Thu, 18 May 2006 09:23:21 +0300 (EEST) Received: from rautu (eukaryote69.gprs.dnafinland.fi [62.78.106.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 257171400B1; Thu, 18 May 2006 09:23:15 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 855E8F01E3; Thu, 18 May 2006 09:23:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.4820.496022.112591@rautu.tutpro.com> Date: Thu, 18 May 2006 09:23:16 +0300 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <446BB2A1.8080700@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Paul Kyzivat writes: > Based on what I am hearing, it seem like the best course might be to > deprecate SIPS and begin work on something else that provides some > useful security properties. exactly, 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 May 18 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 1FgiY1-00046s-Ew; Thu, 18 May 2006 09:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiXz-00046I-Uh for sip@ietf.org; Thu, 18 May 2006 09:28:11 -0400 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgiXx-000137-Nv for sip@ietf.org; Thu, 18 May 2006 09:28:11 -0400 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.6/8.12.11) with ESMTP id k4IDRpJh062337; Thu, 18 May 2006 09:28:00 -0400 (EDT) From: "Brett Tate" To: "'Bolt Vlatko'" , Subject: RE: [Sip] SIP bug 760 - Can multiple transports be tried on a singleDNS lookup? Date: Thu, 18 May 2006 09:27:51 -0400 Message-ID: <000001c67a7e$e04564f0$1d28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <20060516080007.24968.qmail@web53108.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 > Bug 760 in SIP working group, http://bugs.sipit.net/show_bug.cgi?id=760, > clarifies that reattempts in case of failures should be limited > only to one transport determined by 3263/NAPTR procesing. > It still has status NEW (it hasn't been resolved yet). > Is this well known, recognized fault that should be avoided > in implementation of RFC 3263 in SIP products or there > are different opinions in SIP working group? The selection of only 1 transport by rfc3263 is correct; and devices desiring compliance must follow the rfc. The bug is documented against rfc3261 to ensure it doesn't imply an incorrect interpretation of rfc3263. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 11:48:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkgd-00054J-Oj; Thu, 18 May 2006 11:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkgc-00054E-P7 for sip@ietf.org; Thu, 18 May 2006 11:45:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgkga-0001TN-B0 for sip@ietf.org; Thu, 18 May 2006 11:45:14 -0400 Received: from [192.168.1.4] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4IFkGdC003816 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 18 May 2006 10:46:18 -0500 In-Reply-To: <446BFE27.4070909@opencloud.com> References: <446BFE27.4070909@opencloud.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question Date: Thu, 18 May 2006 10:44:57 -0500 To: Ben Evans X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 May 17, 2006, at 11:55 PM, Ben Evans wrote: > Hi, I am trying to figure out what should be a simple proxying > scenario using draft-ietf-sip-outbound-03. Consider the following > scenario: > > UA1 -------> proxy ------- UA2 > flow > > 1. UA1 forms a flow to a proxy/registrar (no edge proxies involved) > and registers successfully. > > 2. UA2 makes a call to UA1 (UA2 may or may not have a flow to the > proxy, it does not matter here). > > 3. The proxy receives the INVITE, looks up UA1's AOR (the Request- > URI) in its location service, and finds the contact URI and the > flow information. The proxy then uses the flow to send the request > to UA1. The proxy also adds itself to the Record-Route header. > > 4. UA1 responds with 200 OK, which is forwarded to UA2. > > 5. UA2 now has to send the ACK. It forms the ACK request using > UA1's contact URI as the Request-URI, and the route set from the > dialog. > > 6. The proxy receives the ACK from UA2... > > My problem is: how does the proxy know to send the ACK out on the > correct flow to UA1?? > > Because the ACK's Request-URI contains UA1's contact URI, not the > AOR, the proxy would normally not do a location service lookup (the > contact URI is a physical IP address/port). So how does the proxy > obtain the flow information from the location service so that it > can send the ACK (and any future mid-dialog requests) on the > correct flow? What am I missing? My theory is that the proxy should use the "double record routing trick". As such, it inserts two R-R values. The first identifies the interface and flow binding for UA1, and the second identifies the interface as seen by UA2. When the proxy receives the ACK at step 6, it pops the first route (its interface facing UA2). It then inspects the next route to figure out where to send. Since this next route is also "local", it pops this route field, picks the flow from the information in that route field, and puts the ACK onto the flow towards UA1. We originally developed this trick to work with proxies that have more than one interface, but since the flow identifier is sort of a "virtual interface", the technique should work here. -- 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 May 18 14:47:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnUW-0006Tm-79; Thu, 18 May 2006 14:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnUU-0006T5-QE for sip@ietf.org; Thu, 18 May 2006 14:44:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnUT-0003fN-Gm for sip@ietf.org; Thu, 18 May 2006 14:44:54 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 May 2006 14:44:53 -0400 X-IronPort-AV: i="4.05,142,1146456000"; d="scan'208"; a="88873378:sNHT30466924" 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 k4IIiqvH019240; Thu, 18 May 2006 14:44:53 -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.211); Thu, 18 May 2006 14:44:52 -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-audet-sip-sips-guidelines: sip and sips contacts inRegistrations Date: Thu, 18 May 2006 14:44:51 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E591B@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts inRegistrations Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAdskEwAC00aDA= From: "Michael Hammer \(mhammer\)" To: "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 18 May 2006 18:44:52.0797 (UTC) FILETIME=[265886D0:01C67AAB] 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 Security is only one aspect of the behavior associated with SIP. Remind me again why this one behavior rose to the level of having a separate URI designation? =20 I think the idea of deprecating sips and addressing the behavior of this feature like other mechanisms negotiated in SIP via headers or parameters makes more sense. The issue of what sip address gets registered then is moot. Then we could re-visit what it is we think we wanted to do wrt security requests and validating that the request was in fact honored. Security: header, options-tag: security anyone??? Mike > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Wednesday, May 17, 2006 5:16 PM > To: IETF SIP List > Subject: [Sip] draft-audet-sip-sips-guidelines: sip and sips=20 > contacts inRegistrations >=20 > Jonathan made a proposal that Contacts in registrations be=20 > automatically "upgradable/downgradable" between sip and sips.=20 >=20 > His exact wording: > > I would propose that it is never > > necessary to include separate contacts for sip and sips. If a=20 > > registration is sent such that each hop was over TLS (done=20 > by having=20 > > the r-uri in the registration be a sips URI), then that=20 > contact (and=20 > > the associated secure path URI) can be used for requests=20 > sent to sip=20 > > or sips AOR. If a request is sent to a SIPS AOR, the proxy sets the=20 > > r-uri to a sips version of the contact. If a request is=20 > sent to a SIP=20 > > AOR, the r-uri is a sip version of the contact. >=20 > The draft I wrote actually takes the opposite approach. >=20 > It proposes that the UA always explicitely registers sip and=20 > sips contacts (in the same registration) in order to bind=20 > each one to the AOR. The AOR itself however is=20 > "upgradable/downgradable" the same way Jonathan is saying. >=20 > It has the advantage that a UA can then specifically request=20 > to be reachable ONLY using a sips contact, ONLY using a sip=20 > contact, or BOTH (and also specify q-value). It also allows=20 > to explicitely say if it is reachable with UDP (again, with a=20 > q-value). This could be very useful for a UA that has a=20 > policy of "always TLS, never TLS, either (TLS prefered), or=20 > either (non-TLS prefered). I don't think this is easily=20 > achievable with Jonathan's proposal. >=20 > Other comments? >=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 May 18 14:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnYB-0007d0-Tn; Thu, 18 May 2006 14:48:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnYB-0007cl-4D for sip@ietf.org; Thu, 18 May 2006 14:48:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnYA-0003xe-Ss for sip@ietf.org; Thu, 18 May 2006 14:48:43 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 May 2006 14:48:43 -0400 X-IronPort-AV: i="4.05,142,1146456000"; d="scan'208"; a="88873781:sNHT36565184" 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 k4IImgvF020057; Thu, 18 May 2006 14:48:42 -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.211); Thu, 18 May 2006 14:48:42 -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-audet-sip-sips-guidelines: usage of transport=tls Date: Thu, 18 May 2006 14:48:41 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E5923@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAdXIkgAC3f6rA= From: "Michael Hammer \(mhammer\)" To: "Francois Audet" , "IETF SIP List" X-OriginalArrivalTime: 18 May 2006 18:48:42.0375 (UTC) FILETIME=[AF2F5970:01C67AAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Also, how does one know that every hop on the way included itself in the Via header? ... if the intent is to scan the Via header list to verify every hop used tls or ipsec or whatever. Mike =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Wednesday, May 17, 2006 5:03 PM > To: IETF SIP List > Subject: [Sip] draft-audet-sip-sips-guidelines: usage of = transport=3Dtls >=20 > Another point made by Jonathan is that transport=3Dtls would=20 > mean just a particular hop, not end-to-end (like sips). >=20 > I have received the same comments from others. Personally,=20 > I'm not sure why this is needed. I think that it could be=20 > deprecated entirely (which was my interpretation of RFC=20 > 3261). That role in my mind is already fullfilled by the Via=20 > header. That would take care of the contact URI. >=20 > I'm not opposed to keeping it, but I just can't understand=20 > where it actually helps.=20 >=20 > If we DO decide to keep it, then, we also need to add a=20 > tls-sctp (as was done for the Via field already). >=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 May 18 15:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnhZ-0002Qf-QZ; Thu, 18 May 2006 14:58:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnhY-0002Qa-NU for sip@ietf.org; Thu, 18 May 2006 14:58:24 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnhX-0004YE-FE for sip@ietf.org; Thu, 18 May 2006 14:58:24 -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 k4IIrA621157; Thu, 18 May 2006 14:53:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: sip and sips contactsinRegistrations Date: Thu, 18 May 2006 13:58:07 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C29F781@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: sip and sips contactsinRegistrations Thread-Index: AcZ5fn8+PPLCsgHOSPyHlrM+/NAUnwAdskEwAC00aDAAAHXPUA== From: "Samir Srivastava" To: "Michael Hammer \(mhammer\)" , "Francois Audet" , "IETF SIP List" 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 I think the idea of deprecating sips and addressing the behavior of this feature like other mechanisms negotiated in SIP via headers or parameters makes more sense. The issue of what sip address gets registered then is moot. Then we could re-visit what it is we think we wanted to do wrt security requests and validating that the request was in fact honored. Security: header, options-tag: security anyone??? SS>> This is the same I said earlier on this "I am working on a proposal where UAC states what cipher suites it needs in the path with the qValues in a header. UAC puts required cipher-suites with Proxy-Require and Require option tags. If the UAC desired level of security is not provided in the path, request is rejected by the proxy which is reached with the desired level of security. UAC can decide what to do if desired level of security is not provided end to end. It proposes to include the ciphersuites in the via header too for the UAS Knowledge. " Thx Samir _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 18 16:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgors-0003x1-2b; Thu, 18 May 2006 16:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgorq-0003wj-OP for sip@ietf.org; Thu, 18 May 2006 16:13:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgorp-0002Se-DS for sip@ietf.org; Thu, 18 May 2006 16:13:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 18 May 2006 13:13:05 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="279151765:sNHT32315144" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4IKD46g009972; Thu, 18 May 2006 13:13:04 -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 k4IKD3BF008253; Thu, 18 May 2006 13:13:04 -0700 (PDT) Received: from xmb-sjc-231.amer.cisco.com ([128.107.191.73]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 13:12:58 -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] draft-audet-sip-sips-guidelines: usage of transport=tls Date: Thu, 18 May 2006 13:12:56 -0700 Message-ID: <49DFEF82990374449378AD1198F39F8B0195F41D@xmb-sjc-231.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Thread-Index: AcZ6Qu9NEOaIUxe/TsOPs9E1yWnmxQAdCUbA From: "Charles Eckel \(eckelcu\)" To: "Juha Heinanen" , "Francois Audet" X-OriginalArrivalTime: 18 May 2006 20:12:58.0759 (UTC) FILETIME=[75065170:01C67AB7] DKIM-Signature: a=rsa-sha1; q=dns; l=1433; t=1147983184; x=1148847184; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckelcu@cisco.com; z=From:=22Charles=20Eckel=20\(eckelcu\)=22=20 |Subject:RE=3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20usage=20of=20transp ort=3Dtls; X=v=3Dcisco.com=3B=20h=3D/2ORdAxeFRTZYmZfWr5bkO4osrg=3D; b=aQdxXzUdZe4rwRxKodXM8z+fS+fu+eLcw9AsDEZK7nNxEdQGuxesc/5W5/AzIxWu2daYvGw5 Udn2T16G48bCO6UakphH+BXeXvvwFNUBfGiQ8O9AAZ5rQ0PDJgKyX1v9; Authentication-Results: sj-dkim-4.cisco.com; header.From=eckelcu@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Wednesday, May 17, 2006 11:14 PM > To: Francois Audet > Cc: IETF SIP List > Subject: [Sip] draft-audet-sip-sips-guidelines: usage of = transport=3Dtls >=20 > Francois Audet writes: >=20 > > I have received the same comments from others. Personally,=20 > I'm not sure > > why this is needed. I think that it could be deprecated=20 > entirely (which > > was my interpretation of RFC 3261). That role in my mind=20 > is already=20 > > fullfilled by the Via header. That would take care of the contact > > URI. >=20 > without transport=3Dtls, how can you, for example, tell to your proxy = to > use tls to a particular PSTN gw? I think this is a bad idea. Why tell your proxy how to do its job. This means you know something about the network architecture and can micro manage the proxy. Maybe the proxy wants to use IPSEC to talk to the GW, or maybe it wants to send it to another trusted proxy over some secure channel and let that proxy handle it? Cheers, Charles >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 18 16:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp2D-0001Gs-Vn; Thu, 18 May 2006 16:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgp2C-0001Gi-OS for sip@ietf.org; Thu, 18 May 2006 16:23:48 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgp28-000391-Bk for sip@ietf.org; Thu, 18 May 2006 16:23:48 -0400 Received: by tutpro.com (Postfix, from userid 65534) id D9EC01400A2; Thu, 18 May 2006 23:23:42 +0300 (EEST) Received: from rautu (mitosis229.gprs.dnafinland.fi [62.78.122.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4FFC613F8AD; Thu, 18 May 2006 23:23:34 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B580DF01D4; Thu, 18 May 2006 23:23:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17516.55239.669595.413587@rautu.tutpro.com> Date: Thu, 18 May 2006 23:23:35 +0300 From: Juha Heinanen To: "Charles Eckel (eckelcu)" Subject: RE: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls In-Reply-To: <49DFEF82990374449378AD1198F39F8B0195F41D@xmb-sjc-231.amer.cisco.com> References: <49DFEF82990374449378AD1198F39F8B0195F41D@xmb-sjc-231.amer.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Charles Eckel (eckelcu) writes: > I think this is a bad idea. Why tell your proxy how to do its job. This > means you know something about the network architecture and can micro > manage the proxy. Maybe the proxy wants to use IPSEC to talk to the GW, > or maybe it wants to send it to another trusted proxy over some secure > channel and let that proxy handle it? hello? take for example a look at openser. it lcr module has a database of gateways serving different prefixes and using different transport protocols. when a request i given to openser's transaction machine for forwarding, transport parameter of R-URI tells, which transport protocol is for used for that destination. without transport parameter, it would not have a clue. -- 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 May 18 17:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpcH-0001Gq-1F; Thu, 18 May 2006 17:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpcG-0001Gl-4c for sip@ietf.org; Thu, 18 May 2006 17:01:04 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgpcC-0005tK-Q4 for sip@ietf.org; Thu, 18 May 2006 17:01:04 -0400 Received: from [192.168.1.4] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4IL27Ii004973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 18 May 2006 16:02:08 -0500 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E591B@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3017E591B@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: sip and sips contacts inRegistrations Date: Thu, 18 May 2006 16:00:51 -0500 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 May 18, 2006, at 1:44 PM, Michael Hammer ((mhammer)) wrote: > Security is only one aspect of the behavior associated with SIP. > Remind > me again why this one behavior rose to the level of having a separate > URI designation? Here's how I remember it: we didn't want to figure out how to use starttls, which means having two ports (one "secure"-- 5061, one not, 5060), and having two ports means having two URI schemes with different default port numbers. -- 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 May 18 17:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpix-0004a5-0N; Thu, 18 May 2006 17:07:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpiv-0004Zz-4I for sip@ietf.org; Thu, 18 May 2006 17:07:57 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgpit-0006YO-Pd for sip@ietf.org; Thu, 18 May 2006 17:07:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4IL2o625200; Thu, 18 May 2006 17:02:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Date: Thu, 18 May 2006 16:07:06 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C29FA1D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Thread-Index: AcZ6Qu9NEOaIUxe/TsOPs9E1yWnmxQAdCUbAAAGoxcA= From: "Samir Srivastava" To: "Charles Eckel \(eckelcu\)" , "Juha Heinanen" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 this is a bad idea. Why tell your proxy how to do its job. This means you know something about the network architecture and can micro manage the proxy. Maybe the proxy wants to use IPSEC to talk to the GW, or maybe it wants to send it to another trusted proxy over some secure channel and let that proxy handle it? SS>> Being a UAC I need to make sure the desired level of security is not compromised in the path. If it cannot be provided, It should be rejected and UAC can try with other secondary proxies. It is asking for level of security, not how it does. Cheers, Charles >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 18 17:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpt3-0001RS-W7; Thu, 18 May 2006 17:18:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpt2-0001RK-Oa for sip@ietf.org; Thu, 18 May 2006 17:18:24 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgpt1-00078t-Er for sip@ietf.org; Thu, 18 May 2006 17:18:24 -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 k4ILIJG06705; Thu, 18 May 2006 17:18:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Date: Thu, 18 May 2006 16:18:15 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60C30EA44@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: usage of transport=tls Thread-Index: AcZ6Qu9NEOaIUxe/TsOPs9E1yWnmxQAdCUbAAAGoxcAAALH0EA== From: "Samir Srivastava" To: "Samir Srivastava" , "Charles Eckel \(eckelcu\)" , "Juha Heinanen" , "Francois Audet" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Sorry. I mis-understood the context.=20 Samir -----Original Message----- From: Srivastava, Samir [SC100:8826:EXCH]=20 Sent: Thursday, May 18, 2006 2:07 PM To: Charles Eckel (eckelcu); Juha Heinanen; Audet, Francois [SC100:3055:EXCH] Cc: IETF SIP List Subject: RE: [Sip] draft-audet-sip-sips-guidelines: usage of transport=3Dtls I think this is a bad idea. Why tell your proxy how to do its job. This means you know something about the network architecture and can micro manage the proxy. Maybe the proxy wants to use IPSEC to talk to the GW, or maybe it wants to send it to another trusted proxy over some secure channel and let that proxy handle it? SS>> Being a UAC I need to make sure the desired level of security is not compromised in the path. If it cannot be provided, It should be rejected and UAC can try with other secondary proxies. It is asking for level of security, not how it does. Cheers, Charles >=20 > -- juha >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 21:45:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgu0d-0003rh-39; Thu, 18 May 2006 21:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgu0Z-0003jo-VY for sip@ietf.org; Thu, 18 May 2006 21:42:27 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgu0Y-00065A-Li for sip@ietf.org; Thu, 18 May 2006 21:42:27 -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 k4J1gE809990; Thu, 18 May 2006 21:42:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 18 May 2006 20:42:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09C32913@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ6CkM9d3v/x554RtqZwXmxMbZFIwAzJ/Mg From: "Francois Audet" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 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 > Based on what I am hearing, it seem like the best course might be to=20 > deprecate SIPS and begin work on something else that provides some=20 > useful security properties. While it is true that using sips as an indicator of security is useless (and probably harmful), it is very useful in an AOR as an indicator that an address is to only be contacted using TLS. It is also useful=20 potentially useful to specify that a request is supposed to be sent over tls end-to-end in a Request-URI. =20 The problem with transport=3Dtls were two-fold (as per RFC 3261/26.2.2): 1- It didn't account for TLS over transport other than TCP 2- It only represented a single hop I think everybody is thinking of "sips" in different context, and that it is confusing. The use of sips in an AORs is quite logical. I really don't see how we could deprecate that. If I want to only be reachable with TLS only, I should be able to use sips:bob@example.com as an AOR. I do not believe that an AOR with a transport parameter is an improvement (and it is specifically disallowed in RFC 3261).=20 However the use of sips gets very confusing when it is used=20 in Contacts (and probably other fields as well). In those cases, the use of transport=3Dtls (and transport=3Dtls-sctp if we defined it) would probably be much less confusing. As for Request-URI, I am a little bit on the fence. transport=3Dtls implies that it is only for a single hop. I'm thinking that when Request-URI is an AOR, it could be a sips URI (like when the UA initiates the session),=20 but that routing proxies should only use transport=3Dtls when the select the next target for a request URI. What my draft was trying to do is define exactly what sips would mean in different contextes, whith as little changes as possible to RFC 3261, so we wouldn't be completely backward incompatible. Perhaps it highlighting that it is too complex. Would people be more comfortable with something along the lines of what is described in this email, namely: 1- Reserve the use of sips to AORs (with sip implies sips, but sips doesn't imply sip) 2- Use transport=3Dtls otherwise I think it would solve the registration problem nicely. The AOR would be=20 sip unless ONLY sips is supported.=20 The Contacts would list explicitely all transport supported (transport=3Dtls, transport=3Dtcp, transport=3Dudp). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 21:58:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguEI-0001it-Lv; Thu, 18 May 2006 21:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguEH-0001io-3t for sip@ietf.org; Thu, 18 May 2006 21:56:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FguEG-00070y-P7 for sip@ietf.org; Thu, 18 May 2006 21:56:37 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 18 May 2006 18:56:36 -0700 X-IronPort-AV: i="4.05,143,1146466800"; d="scan'208"; a="1808939060:sNHT32506276" 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/8.12.11) with ESMTP id k4J1uak7032725; Thu, 18 May 2006 18:56:36 -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 k4J1uZsF007405; Thu, 18 May 2006 18:56:35 -0700 (PDT) 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.211); Thu, 18 May 2006 18:56:35 -0700 Received: from [10.21.144.164] ([10.21.144.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 18:56:35 -0700 Message-ID: <446D25D2.70205@cisco.com> Date: Thu, 18 May 2006 21:56:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09C32913@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09C32913@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 01:56:35.0488 (UTC) FILETIME=[758D8200:01C67AE7] DKIM-Signature: a=rsa-sha1; q=dns; l=2891; t=1148003796; x=1148867796; c=relaxed/simple; s=sjdkim8001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D1Tq4UWImuOUpLJBCsAbO7xplgqw=3D; b=APw+gGgpX+WLPom2+vGpNfLRUDodpt68/S2BJYKB75Zgi4/gva8sMZkVo6MVmNJ/X7JUPIuf 2p6hHluUpatr5yrjyK0uQb/TmcDIu6gJIiXWivgyhivzbsrYho663++j; 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: 4b800b1eab964a31702fa68f1ff0e955 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: >> Based on what I am hearing, it seem like the best course might be to >> deprecate SIPS and begin work on something else that provides some >> useful security properties. > > While it is true that using sips as an indicator of security is useless > (and probably harmful), it is very useful in an AOR as an indicator that > an address is to only be contacted using TLS. It is also useful > potentially useful to specify that a request is supposed to be sent over > tls end-to-end in a Request-URI. > The problem with transport=tls were two-fold (as per RFC 3261/26.2.2): > 1- It didn't account for TLS over transport other than TCP > 2- It only represented a single hop > > I think everybody is thinking of "sips" in different context, and that > it is confusing. > > The use of sips in an AORs is quite logical. I really don't see how > we could deprecate that. If I want to only be reachable with TLS > only, I should be able to use sips:bob@example.com as an AOR. I do > not believe that an AOR with a transport parameter is an improvement > (and it is specifically disallowed in RFC 3261). If that is all it does, and use of TLS itself provides no security properties, then what is the point? Aside from using more cpu cycles, how is using TLS better than using TCP? Also, if the only point is to indicate use of TLS and a different default port, what is wrong with DNSSRV for that? We don't have SIPT and SIPU for TCP and UDP, so why SIPS for TLS? > However the use of sips gets very confusing when it is used > in Contacts (and probably other fields as well). In those cases, the > use of transport=tls (and transport=tls-sctp if we defined it) would > probably be much less confusing. > > As for Request-URI, I am a little bit on the fence. transport=tls > implies that it is only for a single hop. I'm thinking that when > Request-URI > is an AOR, it could be a sips URI (like when the UA initiates the > session), > but that routing proxies should only use transport=tls when the select > the > next target for a request URI. > > What my draft was trying to do is define exactly what sips would mean in > different contextes, whith as little changes as possible to RFC 3261, so > we wouldn't be completely backward incompatible. Perhaps it highlighting > that it is too complex. > > Would people be more comfortable with something along the lines of what > is > described in this email, namely: > > 1- Reserve the use of sips to AORs (with sip implies sips, but sips > doesn't > imply sip) > 2- Use transport=tls otherwise > > I think it would solve the registration problem nicely. The AOR would > be > sip unless ONLY sips is supported. > > The Contacts would list explicitely all transport supported > (transport=tls, transport=tcp, transport=udp). > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 22:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguUp-0000d5-70; Thu, 18 May 2006 22:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguUn-0000ZJ-02 for sip@ietf.org; Thu, 18 May 2006 22:13:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FguUm-0007de-O0 for sip@ietf.org; Thu, 18 May 2006 22:13:40 -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 k4J2Da816148; Thu, 18 May 2006 22:13:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 18 May 2006 21:13:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09C3292D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ653mPJXPr5wpPQBmbIm1FUI4QsgAATSXg From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 > > The use of sips in an AORs is quite logical. I really don't=20 > see how we=20 > > could deprecate that. If I want to only be reachable with=20 > TLS only, I=20 > > should be able to use sips:bob@example.com as an AOR. I do=20 > not believe=20 > > that an AOR with a transport parameter is an improvement (and it is=20 > > specifically disallowed in RFC 3261). >=20 > If that is all it does, and use of TLS itself provides no security=20 > properties, then what is the point? Aside from using more cpu cycles,=20 > how is using TLS better than using TCP? I don't see what is so difficult to understand here. If you know me from my AOR sips:bob@example.net, it basically means that you need to use TLS to send requests. Proxies in the middle are also then supposed to use TLS. > Also, if the only point is to indicate use of TLS and a different=20 > default port, what is wrong with DNSSRV for that? There is nothing wrong with that. But there are cases where you can't use it: sips:+15551212@example.net;user=3Dphone is one example. > We don't have SIPT and SIPU for TCP and UDP, so why SIPS for TLS? We do have http and https however. Backtracking a little: our goal is NOT to completely change RFC 3261. We have a responsibility to make sip work with TLS, preferably in a way that is least disruptive as possible to the our customers, i.e., the people who use our specs. Telling them exactly the opposite of what we told them in RFC 3261 is not the right way to do it... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 22:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguWq-0002Wm-LX; Thu, 18 May 2006 22:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguWp-0002Wh-JN for sip@ietf.org; Thu, 18 May 2006 22:15:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FguWp-0007hs-4P for sip@ietf.org; Thu, 18 May 2006 22:15:47 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 18 May 2006 19:15:46 -0700 X-IronPort-AV: i="4.05,143,1146466800"; d="scan'208"; a="279337084:sNHT539519002" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4J2Fk9p005530; Thu, 18 May 2006 19:15:46 -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 k4J2FjHc002618; Thu, 18 May 2006 19:15:45 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn5-251.cisco.com [10.21.88.251]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4J2D8Ml031800; Thu, 18 May 2006 19:13:09 -0700 Message-ID: <446D2A52.4070500@cisco.com> Date: Thu, 18 May 2006 19:15: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 Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09C32913@zrc2hxm0.corp.nortel.com> <446D25D2.70205@cisco.com> In-Reply-To: <446D25D2.70205@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=4218; t=1148004946; x=1148868946; c=relaxed/simple; s=sjdkim2001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=rquNW3v7cHUCu2mDMJc+gYceKp/sZBiXOVawMEw2jj0eH3/v+3LbsoSCdeA5OBn2OwGfJmLn KAOHz8s+ijHUCe0tqk5zngPuvjaMUvq7FbhuD2I8p1NCOSD63FpXDrUy; X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 The one thing that would be nice to preserve out of SIPS -- maybe by some other mechanism -- is the ability for a UAC to _request_ that the proxies do their best to transport things over tls (or what have you, "secure" to my mind is a little nebulous, but others may disagree). Isn't this what proxy-require is supposed to useful for? I believe that I saw somebody propose something like that. It sounds pretty reasonable to me. Proxy-require has the nice property that the UAC gets to figure out what to do if something goes wrong, and it probably comports less of the mistaken impression that you can will a proxy into doing something that it may out of malice not want to do. Obviously transport=tls suffers from the problem that it doesn't convey the semantic "and thence for ever after". I'm not sure what it's purpose in life is, but that's most likely just me. Mike Paul Kyzivat wrote: > > > Francois Audet wrote: > >>> Based on what I am hearing, it seem like the best course might be to >>> deprecate SIPS and begin work on something else that provides some >>> useful security properties. >> >> >> While it is true that using sips as an indicator of security is useless >> (and probably harmful), it is very useful in an AOR as an indicator that >> an address is to only be contacted using TLS. It is also useful >> potentially useful to specify that a request is supposed to be sent over >> tls end-to-end in a Request-URI. > > >> The problem with transport=tls were two-fold (as per RFC 3261/26.2.2): >> 1- It didn't account for TLS over transport other than TCP >> 2- It only represented a single hop >> >> I think everybody is thinking of "sips" in different context, and that >> it is confusing. >> >> The use of sips in an AORs is quite logical. I really don't see how >> we could deprecate that. If I want to only be reachable with TLS >> only, I should be able to use sips:bob@example.com as an AOR. I do >> not believe that an AOR with a transport parameter is an improvement >> (and it is specifically disallowed in RFC 3261). > > > If that is all it does, and use of TLS itself provides no security > properties, then what is the point? Aside from using more cpu cycles, > how is using TLS better than using TCP? > > Also, if the only point is to indicate use of TLS and a different > default port, what is wrong with DNSSRV for that? > > We don't have SIPT and SIPU for TCP and UDP, so why SIPS for TLS? > >> However the use of sips gets very confusing when it is used in >> Contacts (and probably other fields as well). In those cases, the >> use of transport=tls (and transport=tls-sctp if we defined it) would >> probably be much less confusing. >> >> As for Request-URI, I am a little bit on the fence. transport=tls >> implies that it is only for a single hop. I'm thinking that when >> Request-URI >> is an AOR, it could be a sips URI (like when the UA initiates the >> session), but that routing proxies should only use transport=tls when >> the select >> the >> next target for a request URI. >> >> What my draft was trying to do is define exactly what sips would mean in >> different contextes, whith as little changes as possible to RFC 3261, so >> we wouldn't be completely backward incompatible. Perhaps it highlighting >> that it is too complex. >> >> Would people be more comfortable with something along the lines of what >> is >> described in this email, namely: >> >> 1- Reserve the use of sips to AORs (with sip implies sips, but sips >> doesn't >> imply sip) >> 2- Use transport=tls otherwise >> >> I think it would solve the registration problem nicely. The AOR would >> be sip unless ONLY sips is supported. >> The Contacts would list explicitely all transport supported >> (transport=tls, transport=tcp, transport=udp). >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 18 22:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgua6-000527-7F; Thu, 18 May 2006 22:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgua5-000522-7h for sip@ietf.org; Thu, 18 May 2006 22:19:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgua1-0007pg-Ul for sip@ietf.org; Thu, 18 May 2006 22:19:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 18 May 2006 19:19:05 -0700 X-IronPort-AV: i="4.05,143,1146466800"; d="scan'208"; a="1808947102:sNHT30984124" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4J2J5p2000821; Thu, 18 May 2006 19:19:05 -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 k4J2J5B7027227; Thu, 18 May 2006 19:19:05 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn5-251.cisco.com [10.21.88.251]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4J2GS20031871; Thu, 18 May 2006 19:16:29 -0700 Message-ID: <446D2B1A.2050205@cisco.com> Date: Thu, 18 May 2006 19:19:06 -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] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09C3292D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09C3292D@zrc2hxm0.corp.nortel.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=616; t=1148005145; x=1148869145; c=relaxed/simple; s=sjdkim4001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=uHCDN/pDpZKTMPy0PMDgNalYI7kDTt+Tg823LNdEjugiA0figbcqHBLn574WQYcrvSlDhE7m o2D9FaS2ZJTNjDB2WRMfgKdOzb2MNvNPjJOTkt9g1miQ32PqBfX5i2BU; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: IETF SIP List , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: >We do have http and https however. > >Backtracking a little: our goal is NOT to completely change RFC 3261. We > >have a responsibility to make sip work with TLS, preferably in a way >that >is least disruptive as possible to the our customers, i.e., the people >who >use our specs. > >Telling them exactly the opposite of what we told them in RFC 3261 is >not >the right way to do it... > > If we told them that SIPS was "secure" in any way that's even vaguely similar to https, then we were mistaken, and we should cut our losses as soon as possible. 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 Thu May 18 23:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgvrl-0006jd-3n; Thu, 18 May 2006 23:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgvrj-0006jV-8z for sip@ietf.org; Thu, 18 May 2006 23:41:27 -0400 Received: from yass.opencloud.co.nz ([131.203.101.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgvrh-0002vs-R6 for sip@ietf.org; Thu, 18 May 2006 23:41:27 -0400 Received: from tortilla.opencloud.co.nz ([192.168.0.37]) by yass.opencloud.co.nz with asmtp (TLS-1.0:DHE_RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1Fgvrb-0006Hx-Kk; Fri, 19 May 2006 15:41:19 +1200 Message-ID: <446D3E5E.4070800@opencloud.com> Date: Fri, 19 May 2006 15:41:18 +1200 From: Ben Evans User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question References: <446BFE27.4070909@opencloud.com> <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> In-Reply-To: <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: > > On May 17, 2006, at 11:55 PM, Ben Evans wrote: >> [...] >> Because the ACK's Request-URI contains UA1's contact URI, not the >> AOR, the proxy would normally not do a location service lookup (the >> contact URI is a physical IP address/port). So how does the proxy >> obtain the flow information from the location service so that it can >> send the ACK (and any future mid-dialog requests) on the correct >> flow? What am I missing? > > > My theory is that the proxy should use the "double record routing > trick". As such, it inserts two R-R values. The first identifies the > interface and flow binding for UA1, and the second identifies the > interface as seen by UA2. > > When the proxy receives the ACK at step 6, it pops the first route (its > interface facing UA2). It then inspects the next route to figure out > where to send. Since this next route is also "local", it pops this > route field, picks the flow from the information in that route field, > and puts the ACK onto the flow towards UA1. > > We originally developed this trick to work with proxies that have more > than one interface, but since the flow identifier is sort of a "virtual > interface", the technique should work here. Thanks Dean, this worked really well. Should this technique should be mentioned in the draft? Or maybe it is already obvious to those in the know! Cheers Ben > > -- > Dean > > -- Ben Evans / Software Engineer / Open Cloud / ben.evans@opencloud.com Tel: +6421636182 / PO Box 19210, Wellington, NZ / www.opencloud.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 May 19 00:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgwlp-0007FR-BF; Fri, 19 May 2006 00:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgwlm-0007F8-US for sip@ietf.org; Fri, 19 May 2006 00:39:23 -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 1Fgwlm-0000Cj-LD for sip@ietf.org; Fri, 19 May 2006 00:39:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 May 2006 21:39:23 -0700 X-IronPort-AV: i="4.05,143,1146466800"; d="scan'208"; a="322795811:sNHT31520118" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4J4dMLV023258; Thu, 18 May 2006 21:39:22 -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 k4J4dLB7011249; Thu, 18 May 2006 21:39:21 -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); Thu, 18 May 2006 21:39:21 -0700 Received: from [10.21.144.164] ([10.21.144.164]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 21:39:20 -0700 Message-ID: <446D4BF3.6070807@cisco.com> Date: Fri, 19 May 2006 00:39:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09C3292D@zrc2hxm0.corp.nortel.com> <446D2B1A.2050205@cisco.com> In-Reply-To: <446D2B1A.2050205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 04:39:21.0175 (UTC) FILETIME=[325B1670:01C67AFE] DKIM-Signature: a=rsa-sha1; q=dns; l=1531; t=1148013562; x=1148877562; c=relaxed/simple; s=sjdkim4001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D1Tq4UWImuOUpLJBCsAbO7xplgqw=3D; b=YU3kq4skfPuvOUQwXFUOr8oLZZgUVd6vOsaiifm3Wi/lKoMxRppwQpibC4wTI7snFAUEff4c WZB6l+HoicFe33yIYQ+McqlJKsta15vI9BkjE+391QgQvtKa4P4wCz5v; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 wrote: > Francois Audet wrote: > >> We do have http and https however. Yes we do. The *only* value of https over http is that provides that I will have a secure connection with the a server that is authorized to use that name. >> Backtracking a little: our goal is NOT to completely change RFC 3261. We >> >> have a responsibility to make sip work with TLS, preferably in a way >> that >> is least disruptive as possible to the our customers, i.e., the people >> who >> use our specs. >> >> Telling them exactly the opposite of what we told them in RFC 3261 is >> not >> the right way to do it... >> >> > If we told them that SIPS was "secure" in any way that's even vaguely > similar > to https, then we were mistaken, and we should cut our losses as soon as > possible. Without that guarantee, what is the point? I guess we still have the indication that the target of the URI *requires* that a secure communication path be used to reach it. But if we lack a way to deliver on the guarantee, it is an empty one. In some environments based on transitive trust, *maybe* hop by hop security and an understanding that a server with credentials for the URI actually received the request (even though it may have passed it on) is enough of a guarantee. I guess the existing rules in 3261 are based on an assumption like that, though it obviously isn't so clear. One thing that is lacking there is a clear definition of scope of transitive trust. 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 May 19 03:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxT-00069j-1E; Fri, 19 May 2006 02:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxP-00067N-C6 for sip@ietf.org; Fri, 19 May 2006 02:59:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgyvA-0008Ot-96 for sip@ietf.org; Fri, 19 May 2006 02:57:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2006 23:57:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,144,1146466800"; d="scan'208"; a="28378033:sNHT22684420" 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 k4J6v9vH016692; Fri, 19 May 2006 02:57:11 -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.211); Fri, 19 May 2006 02:57:10 -0400 Received: from [192.168.1.100] ([10.86.242.69]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 02:57:10 -0400 Message-ID: <446D3E5F.8000909@cisco.com> Date: Thu, 18 May 2006 23:41:19 -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: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 06:57:10.0352 (UTC) FILETIME=[732B5D00:01C67B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List Subject: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Jonathan made a proposal that Contacts in registrations be automatically > "upgradable/downgradable" between sip and sips. > > His exact wording: > >>I would propose that it is never >>necessary to include separate contacts for sip and sips. If a >>registration is sent such that each hop was over TLS (done by >>having the >>r-uri in the registration be a sips URI), then that contact (and the >>associated secure path URI) can be used for requests sent to >>sip or sips >>AOR. If a request is sent to a SIPS AOR, the proxy sets the >>r-uri to a >>sips version of the contact. If a request is sent to a SIP AOR, the >>r-uri is a sip version of the contact. > > > The draft I wrote actually takes the opposite approach. > > It proposes that the UA always explicitely registers sip and sips > contacts > (in the same registration) in order to bind each one to the AOR. The AOR > itself > however is "upgradable/downgradable" the same way Jonathan is saying. > > It has the advantage that a UA can then specifically request to be > reachable > ONLY using a sips contact, ONLY using a sip contact, or BOTH (and > also specify q-value). I'm questioning the need for that. In this particular case, I think simplicity trumps features. I think it is an undue burden to require two contacts just to indicate something that should normally be permitted. I would think that in 99.9% of the cases, a UA would be willing to accept calls of eitheFrom sip-bounces@ietf.org Fri May 19 03:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxT-00069j-1E; Fri, 19 May 2006 02:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxP-00067N-C6 for sip@ietf.org; Fri, 19 May 2006 02:59:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgyvA-0008Ot-96 for sip@ietf.org; Fri, 19 May 2006 02:57:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2006 23:57:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,144,1146466800"; d="scan'208"; a="28378033:sNHT22684420" 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 k4J6v9vH016692; Fri, 19 May 2006 02:57:11 -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.211); Fri, 19 May 2006 02:57:10 -0400 Received: from [192.168.1.100] ([10.86.242.69]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 02:57:10 -0400 Message-ID: <446D3E5F.8000909@cisco.com> Date: Thu, 18 May 2006 23:41:19 -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: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 06:57:10.0352 (UTC) FILETIME=[732B5D00:01C67B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF SIP List Subject: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations X-BeenThere: sip@ietf.org X-Mailman-Version: 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: > Jonathan made a proposal that Contacts in registrations be automatically > "upgradable/downgradable" between sip and sips. > > His exact wording: > >>I would propose that it is never >>necessary to include separate contacts for sip and sips. If a >>registration is sent such that each hop was over TLS (done by >>having the >>r-uri in the registration be a sips URI), then that contact (and the >>associated secure path URI) can be used for requests sent to >>sip or sips >>AOR. If a request is sent to a SIPS AOR, the proxy sets the >>r-uri to a >>sips version of the contact. If a request is sent to a SIP AOR, the >>r-uri is a sip version of the contact. > > > The draft I wrote actually takes the opposite approach. > > It proposes that the UA always explicitely registers sip and sips > contacts > (in the same registration) in order to bind each one to the AOR. The AOR > itself > however is "upgradable/downgradable" the same way Jonathan is saying. > > It has the advantage that a UA can then specifically request to be > reachable > ONLY using a sips contact, ONLY using a sip contact, or BOTH (and > also specify q-value). I'm questioning the need for that. In this particular case, I think simplicity trumps features. I think it is an undue burden to require two contacts just to indicate something that should normally be permitted. I would think that in 99.9% of the cases, a UA would be willing to accept calls of either type. I can't see any case where it would only accept sip and not sips. I can imagine cases (secure phone service) where it would only accept sips. However, as Juha points out in his mail, it can simply reject an incoming call which was received over sip. All your proposal does is push that rejection into the network. For what benefit? -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 May 19 03:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxV-0006A6-PA; Fri, 19 May 2006 02:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxP-00067d-CO for sip@ietf.org; Fri, 19 May 2006 02:59:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgyvA-0008Os-2w for sip@ietf.org; Fri, 19 May 2006 02:57:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2006 02:57:12 -0400 X-IronPort-AV: i="4.05,144,1146456000"; d="scan'208"; a="88916509:sNHT30940528" 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 k4J6v9vF016692; Fri, 19 May 2006 02:57:11 -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.211); Fri, 19 May 2006 02:57:09 -0400 Received: from [192.168.1.100] ([10.86.242.69]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 02:57:08 -0400 Message-ID: <446D3D6A.6060604@cisco.com> Date: Thu, 18 May 2006 23:37: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: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> In-Reply-To: <17516.4820.496022.112591@rautu.tutpro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 06:57:08.0493 (UTC) FILETIME=[720FB3D0:01C67B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 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 Well, before we go and deprecate stuff let us not make the perfect the enemy of the good. Yes, as Dean and others have pointed out, sips makes the assumption that all of the proxies along the path are "good", and that they have followed the rules about sips treatment. There is no dispute that this does NOT protect against attacks where the proxies are malicious and choose to ignore sips. However, I will assert that ther type. I can't see any case where it would only accept sip and not sips. I can imagine cases (secure phone service) where it would only accept sips. However, as Juha points out in his mail, it can simply reject an incoming call which was received over sip. All your proposal does is push that rejection into the network. For what benefit? -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 May 19 03:02:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxV-0006A6-PA; Fri, 19 May 2006 02:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgyxP-00067d-CO for sip@ietf.org; Fri, 19 May 2006 02:59:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgyvA-0008Os-2w for sip@ietf.org; Fri, 19 May 2006 02:57:14 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 May 2006 02:57:12 -0400 X-IronPort-AV: i="4.05,144,1146456000"; d="scan'208"; a="88916509:sNHT30940528" 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 k4J6v9vF016692; Fri, 19 May 2006 02:57:11 -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.211); Fri, 19 May 2006 02:57:09 -0400 Received: from [192.168.1.100] ([10.86.242.69]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 19 May 2006 02:57:08 -0400 Message-ID: <446D3D6A.6060604@cisco.com> Date: Thu, 18 May 2006 23:37: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: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> In-Reply-To: <17516.4820.496022.112591@rautu.tutpro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 06:57:08.0493 (UTC) FILETIME=[720FB3D0:01C67B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 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 Well, before we go and deprecate stuff let us not make the perfect the enemy of the good. Yes, as Dean and others have pointed out, sips makes the assumption that all of the proxies along the path are "good", and that they have followed the rules about sips treatment. There is no dispute that this does NOT protect against attacks where the proxies are malicious and choose to ignore sips. However, I will assert that there are a lot of environments where it is a reasonable assumption to make that you are trusting the proxies. Remember, proper SIP operations depends on some level of trust on the proxies. For most deployments, I would assert that there is no reason that a proxy would properly perform normal SIP processing (forwarding of requests and so on), yet not honor sips for some malicious reason. So, sure - there are some number of small cases where the security provided by sips is not sufficient because of an oddball trust relationship with the provider. If your enviroment is not such an environment, then sips isnt good enough and you'll need to use S/MIME. But S/MIME is a whole lot harder to deploy as we know, and I don't want to make that the ONLY choice. *Assuming* you trust the proxies to obey sips, sips provides a lot of nice security properties. It protects me against outside attackers from pretty much doing anything - modifying calls, hijacking calls, detecting call patterns, and so on. I think thats worth preserving. Thanks, Jonathan R. Juha Heinanen wrote: > Paul Kyzivat writes: > > > Based on what I am hearing, it seem like the best course might be to > > deprecate SIPS and begin work on something else that provides some > > useful security properties. > > exactly, 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 > -- 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 re are a lot of environments where it is a reasonable assumption to make that you are trusting the proxies. Remember, proper SIP operations depends on some level of trust on the proxies. For most deployments, I would assert that there is no reason that a proxy would properly perform normal SIP processing (forwarding of requests and so on), yet not honor sips for some malicious reason. So, sure - there are some number of small cases where the security provided by sips is not sufficient because of an oddball trust relationship with the provider. If your enviroment is not such an environment, then sips isnt good enough and you'll need to use S/MIME. But S/MIME is a whole lot harder to deploy as we know, and I don't want to make that the ONLY choice. *Assuming* you trust the proxies to obey sips, sips provides a lot of nice security properties. It protects me against outside attackers from pretty much doing anything - modifying calls, hijacking calls, detecting call patterns, and so on. I think thats worth preserving. Thanks, Jonathan R. Juha Heinanen wrote: > Paul Kyzivat writes: > > > Based on what I am hearing, it seem like the best course might be to > > deprecate SIPS and begin work on something else that provides some > > useful security properties. > > exactly, 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 > -- 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 May 19 05:32:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Iy-0003dc-7v; Fri, 19 May 2006 05:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Iw-0003dX-VE for sip@ietf.org; Fri, 19 May 2006 05:29:54 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh1Iw-0007MW-KO for sip@ietf.org; Fri, 19 May 2006 05:29:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k4J9Trrl028582 for ; Fri, 19 May 2006 03:29:53 -0600 (MDT) 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: 3rd party registration (was RE: [Sip] SIPMIBietf-sip-mib comments) Date: Fri, 19 May 2006 03:29:53 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3rd party registration (was RE: [Sip] SIPMIBietf-sip-mib comments) Thread-Index: AcZ4KDJRWLjIsar/QGe54ZeGCtsaSQAAD+qQADDWwqAAjk83MA== From: "Jean-Francois Mule" To: "SIP IETF" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: sip@ietf.org X-Mailman-Version: 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 close the thread on this, we have removed this object (sipRegAllowThirdParty) from the mib. Thx to Rohan for suggesting the removal and to Dean & all for the discussion. The rationale was: - just get the mib done - given that 3rd-party registration means various different things, it is better to leave this basic use (to!=3Dfrom) out of the = mib. Various definitions include: To !=3D from in register, To !=3D contact, = and variants of these like in 3GPP IMS for AS interactions (see 24.229 section 5.4). - Dean also added that a registrar may have to implement new logic in order to be able to exercise this part of the mib.=20 A new Internet-Draft for the sip mib should appear next week. Kevin and Jean-Francois > -----Original Message----- > From: Bob Natale [mailto:bnatale@nextone.com] > Sent: Tuesday, May 16, 2006 7:24 AM > To: SIP IETF > Subject: RE: 3rd party registration (was RE: [Sip] SIPMIBietf-sip-mib > comments) >=20 > I'd like to second Kevin's vote, as well as Cullen's position > regardless. >=20 > Cheers, > BobN >=20 > -----Original Message----- > From: Kevin Lingle (klingle) [mailto:klingle@cisco.com] > Sent: Monday, May 15, 2006 10:05 AM > To: Cullen Jennings (fluffy); Dean Willis > Cc: SIP IETF; Romascanu, Dan ((Dan)); Paul Kyzivat (pkyzivat); Juergen > Schoenwaelder; Jean-Francois Mule > Subject: RE: 3rd party registration (was RE: [Sip] SIP MIBietf-sip-mib > comments) >=20 > jean-francois, > at this point, i'd vote to simply remove the object. > kevin >=20 > -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Monday, May 15, 2006 10:02 AM > To: Dean Willis > Cc: Paul Kyzivat (pkyzivat); SIP IETF; Romascanu, Dan ((Dan)); > Jean-Francois Mule; Kevin Lingle (klingle); Juergen Schoenwaelder > Subject: Re: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip- > mib > comments) >=20 >=20 > At this point, the value of finishing this MIB far outweighs the value > this discussion will add to the MIB. I will happily support whatever > the > author choose to do to close this issue. >=20 > Cullen >=20 > On May 10, 2006, at 5:19 PM, Dean Willis wrote: >=20 > > > > On May 9, 2006, at 2:23 PM, Paul Kyzivat wrote: > > > >> > >> I have heard of at least one implementation that supports 3rd party > >> registration. > > > > But do we have any need to track and report on 3rd party > registrations >=20 > > at the MIB level differently than we do 1st party registrations? > > > > Or is a registration just a registration from a peg-count > perspective? > > > > -- > > 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 May 19 06:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh2dT-0006UQ-Tv; Fri, 19 May 2006 06:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh2dS-0006UL-8r for sip@ietf.org; Fri, 19 May 2006 06:55:10 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh2dQ-0006v0-OZ for sip@ietf.org; Fri, 19 May 2006 06:55:10 -0400 Received: (qmail 23888 invoked by uid 0); 19 May 2006 10:54:55 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 19 May 2006 10:54:55 -0000 Message-ID: <006e01c67b32$a8551f90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" , "Francois Audet" References: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> <446D3E5F.8000909@cisco.com> Subject: Re: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts inRegistrations Date: Fri, 19 May 2006 12:54:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Francois, Problem with multiple contacts: how do you prevent forking? note that q-order is not sufficient for that To signal that a Contact URI should not be upgraded to SIPS, the UAC could use callee capabilities (RFC3840): Contact: ;schemes="sip,!sips" (signals no upgrading) Note that the reverse case ("sips,!sip") would make less sense, since the UA would be capable of "sip", just not willing. Better to leave this decision to the UA, on a per-call basis (it might reasonably decide this based on where/whom the call is coming from) Regards, Jeroen PS I was expecting to find a callee capability to indicate supported transports, but there is none in RFC3840. Can anyone explain why? ----- Original Message ----- From: "Jonathan Rosenberg" To: "Francois Audet" Cc: "IETF SIP List" Sent: Friday, May 19, 2006 5:41 AM Subject: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts inRegistrations > > > Francois Audet wrote: > >> Jonathan made a proposal that Contacts in registrations be automatically >> "upgradable/downgradable" between sip and sips. His exact wording: >> >>>I would propose that it is never necessary to include separate contacts >>>for sip and sips. If a registration is sent such that each hop was over >>>TLS (done by having the r-uri in the registration be a sips URI), then >>>that contact (and the associated secure path URI) can be used for >>>requests sent to sip or sips AOR. If a request is sent to a SIPS AOR, the >>>proxy sets the r-uri to a sips version of the contact. If a request is >>>sent to a SIP AOR, the r-uri is a sip version of the contact. >> >> >> The draft I wrote actually takes the opposite approach. >> >> It proposes that the UA always explicitely registers sip and sips >> contacts >> (in the same registration) in order to bind each one to the AOR. The AOR >> itself however is "upgradable/downgradable" the same way Jonathan is >> saying. >> >> It has the advantage that a UA can then specifically request to be >> reachable >> ONLY using a sips contact, ONLY using a sip contact, or BOTH (and >> also specify q-value). > > I'm questioning the need for that. > > In this particular case, I think simplicity trumps features. I think it is > an undue burden to require two contacts just to indicate something that > should normally be permitted. I would think that in 99.9% of the cases, a > UA would be willing to accept calls of either type. I can't see any case > where it would only accept sip and not sips. I can imagine cases (secure > phone service) where it would only accept sips. However, as Juha points > out in his mail, it can simply reject an incoming call which was received > over sip. All your proposal does is push that rejection into the network. > For what benefit? > > -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 Fri May 19 10:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6HR-0003zi-Ox; Fri, 19 May 2006 10:48:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6HP-0003zd-Ro for sip@ietf.org; Fri, 19 May 2006 10:48:39 -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 1Fh6HP-00051T-EQ for sip@ietf.org; Fri, 19 May 2006 10:48:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 19 May 2006 07:48:38 -0700 X-IronPort-AV: i="4.05,146,1146466800"; d="scan'208"; a="322836445:sNHT32666618" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4JEmcQr020621; Fri, 19 May 2006 07:48:38 -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 k4JEmcB7012152; Fri, 19 May 2006 07:48:38 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn5-251.cisco.com [10.21.88.251]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4JEjw0p015959; Fri, 19 May 2006 07:45:59 -0700 Message-ID: <446DDAC5.2050906@cisco.com> Date: Fri, 19 May 2006 07:48: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: Jonathan Rosenberg Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> In-Reply-To: <446D3D6A.6060604@cisco.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=3540; t=1148050118; x=1148914118; c=relaxed/simple; s=sjdkim3001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=lTxM8s3mFEh3UmIKz1sZWwetq/fZ3Qbva8X9WB0NESnrXMUGqhsX9E7H/KgbukT2YenuIgLw 6avT0YjCqdyAo27qvhS8Do+h9PQv5wK/7tvGxFbnRvs51UdOvLL6YZXg; X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: IETF SIP List , Juha Heinanen , Francois Audet , 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 Part of the problem is that SIPS is being oversold as somehow similiar to https. It simply is not in any way equivalent for the vast majority of https traffic. That alone is a big problem, IMO, and we've had plenty of confusion on this list to amply demonstrate the dangers of the oversell. Second, I don't buy your assertion that there's some reason I should "trust" proxies, and most especially when they cross domain boundaries -- and most doubly especially when they cross into a service provider boundary. This is hardly black helicopter paranoia at this point. It's these supposedly disinterested third parties that are a real security danger, and SIP needs to deal with them. Saying that S/MIME is the answer is not very satisfying because S/MIME has *no* deployment, nor does there seem to be any movement toward it. What it seems to me that is needed is getting back to the end to end principle, or as end to end as is practicable. If you use intermediate and untrusted proxies for routing, use the routing to get there, but start up a direct conversation with the UAS ideally, or a UAS delegated proxy if necessary. And don't send keys and other goodies until you've done that. _That_ might qualify as SIPS, but what you have now is dangerously misleading. Mike Jonathan Rosenberg wrote: > Well, before we go and deprecate stuff let us not make the perfect the > enemy of the good. > > Yes, as Dean and others have pointed out, sips makes the assumption > that all of the proxies along the path are "good", and that they have > followed the rules about sips treatment. There is no dispute that this > does NOT protect against attacks where the proxies are malicious and > choose to ignore sips. > > However, I will assert that there are a lot of environments where it > is a reasonable assumption to make that you are trusting the proxies. > Remember, proper SIP operations depends on some level of trust on the > proxies. For most deployments, I would assert that there is no reason > that a proxy would properly perform normal SIP processing (forwarding > of requests and so on), yet not honor sips for some malicious reason. > > So, sure - there are some number of small cases where the security > provided by sips is not sufficient because of an oddball trust > relationship with the provider. If your enviroment is not such an > environment, then sips isnt good enough and you'll need to use S/MIME. > But S/MIME is a whole lot harder to deploy as we know, and I don't > want to make that the ONLY choice. > > *Assuming* you trust the proxies to obey sips, sips provides a lot of > nice security properties. It protects me against outside attackers > from pretty much doing anything - modifying calls, hijacking calls, > detecting call patterns, and so on. I think thats worth preserving. > > Thanks, > Jonathan R. > > Juha Heinanen wrote: > >> Paul Kyzivat writes: >> >> > Based on what I am hearing, it seem like the best course might be >> to > deprecate SIPS and begin work on something else that provides >> some > useful security properties. >> >> exactly, 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 Fri May 19 13:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8kA-00016l-IP; Fri, 19 May 2006 13:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8k9-00016g-1x for sip@ietf.org; Fri, 19 May 2006 13:26:29 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8k7-0007ER-NO for sip@ietf.org; Fri, 19 May 2006 13:26:29 -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 k4JHQM011140; Fri, 19 May 2006 13:26:23 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Fri, 19 May 2006 12:26:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09C32FB0@zrc2hxm0.corp.nortel.com> In-Reply-To: <446D3D6A.6060604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ7EXgCyIWuEF52SUyxH3zf117lHwAV74Ww From: "Francois Audet" To: "Jonathan Rosenberg" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: IETF SIP List , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree completely with Jonathan on this one. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Thursday, May 18, 2006 20:37 > To: Juha Heinanen > Cc: Paul Kyzivat; IETF SIP List; Audet, Francois=20 > [SC100:3055:EXCH]; Dean Willis > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 > Well, before we go and deprecate stuff let us not make the=20 > perfect the=20 > enemy of the good. >=20 > Yes, as Dean and others have pointed out, sips makes the=20 > assumption that=20 > all of the proxies along the path are "good", and that they have=20 > followed the rules about sips treatment. There is no dispute=20 > that this=20 > does NOT protect against attacks where the proxies are malicious and=20 > choose to ignore sips. >=20 > However, I will assert that there are a lot of environments=20 > where it is=20 > a reasonable assumption to make that you are trusting the proxies.=20 > Remember, proper SIP operations depends on some level of trust on the=20 > proxies. For most deployments, I would assert that there is no reason=20 > that a proxy would properly perform normal SIP processing=20 > (forwarding of=20 > requests and so on), yet not honor sips for some malicious reason. >=20 > So, sure - there are some number of small cases where the security=20 > provided by sips is not sufficient because of an oddball trust=20 > relationship with the provider. If your enviroment is not such an=20 > environment, then sips isnt good enough and you'll need to=20 > use S/MIME.=20 > But S/MIME is a whole lot harder to deploy as we know, and I=20 > don't want=20 > to make that the ONLY choice. >=20 > *Assuming* you trust the proxies to obey sips, sips provides a lot of=20 > nice security properties. It protects me against outside=20 > attackers from=20 > pretty much doing anything - modifying calls, hijacking=20 > calls, detecting=20 > call patterns, and so on. I think thats worth preserving. >=20 > Thanks, > Jonathan R. >=20 > Juha Heinanen wrote: >=20 > > Paul Kyzivat writes: > >=20 > > > Based on what I am hearing, it seem like the best course=20 > might be=20 > > to > > > deprecate SIPS and begin work on something else that=20 > provides some=20 > > > useful security properties. > >=20 > > exactly, juha > >=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=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=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 >=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 May 19 14:08:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9MU-0005pu-6g; Fri, 19 May 2006 14:06:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9MS-0005pp-Nw for sip@ietf.org; Fri, 19 May 2006 14:06:04 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9MQ-00013U-At for sip@ietf.org; Fri, 19 May 2006 14:06:04 -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 k4JI5w005453; Fri, 19 May 2006 14:05:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 May 2006 13:05:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09C3304D@zrc2hxm0.corp.nortel.com> In-Reply-To: <446D3E5F.8000909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations Thread-Index: AcZ7EXe9Zv4mnheTTUiEuwEBgWS+twAV95pQ From: "Francois Audet" To: "Jonathan Rosenberg" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: IETF SIP List Subject: [Sip] RE: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations X-BeenThere: sip@ietf.org X-Mailman-Version: 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 proposes that the UA always explicitely registers sip and sips=20 > > contacts (in the same registration) in order to bind each=20 > one to the=20 > > AOR. The AOR itself > > however is "upgradable/downgradable" the same way Jonathan=20 > is saying. > >=20 > > It has the advantage that a UA can then specifically request to be=20 > > reachable ONLY using a sips contact, ONLY using a sip=20 > contact, or BOTH=20 > > (and also specify q-value). >=20 > I'm questioning the need for that. >=20 > In this particular case, I think simplicity trumps features.=20 > I think it=20 > is an undue burden to require two contacts just to indicate something=20 > that should normally be permitted. I would think that in 99.9% of the=20 > cases, a UA would be willing to accept calls of either type.=20 > I can't see=20 > any case where it would only accept sip and not sips. I can imagine=20 > cases (secure phone service) where it would only accept sips.=20 > > However,=20 > as Juha points out in his mail, it can simply reject an incoming call=20 > which was received over sip. All your proposal does is push that=20 > rejection into the network. For what benefit? Well, to me that's the issue. The starting point today, is UAs that are deployed and don't support TLS. We want to start introducing UAs that now support TLS. We want to do this in a way that does not impact the network in an undue manner. To me, having calls that fail because they are using the wrong transport is unacceptable. HERF could make a terminal unreachable completely for one thing. This would happen all the time... Granted, in some cases (e.g., if an outbound proxy is used as in SIP-outbound), the outbound proxy has a good way of knowing the transport used by a specific UA. On the other hand, without an outbound proxy, it will be impossible. It gets even worst if a redirect server is used instead of a proxy. I would venture to say that the burden of adding a contact for transport=3Dtls in=20 Registration (compared to state of the art today) is relatively simple. It is much less of a burden then having calls fail all over the place because one expect sips instead of sip (or vice-versa). Going back to the introduction of my first TLS UAs into the network... How do I switch from "try TCP (or UDP) first" to "try TLS first"? If I have 10,000=20 terminals supporting TCP only, and I add my first TLS terminal, does it mean that essentially all call fails the first time? Or that it only fails for calls to the TLS terminal (prompting questions of why the TLS terminal has slow setup time). But, I'm really not wed to a particular mechanism for indicating support for which transport. I see 4 possibilities (thanks to Jeroen for pointing out RFC 3840): 1 - List multiple contacts, with q-values, using the form sip or sips. Jeroen pointed out that it may overlap with the meaning of multiple separate contacts used for forking, creating ambiguity. Also, meaning of sip vs sips is=20 somewhat confusing in this case. (This is what is in my current draft). 2 - List multiple contacts, with q-values as above, but using ;transport=3Dtls instead of sips. Slighly less confusing that (1) perhaps, but still has the forking ambiguity issue. 3 - Use RFC 3840 user agent capabilities "schemes" feature param for sip & sips (including !sip and !sips if required). This implies "all the hops" as opposed to a single hop. Contrary to 1 and 2, it doesn't consist of two contacts, it is one contact with 2 transport capabilities.=20 4 - Define new RFC 3840 user agent capabilties for "transport" feature param. Similar to 3, but would allow for distinguishing hop-by-hop behavior from that last hop.=20 Personnaly, I think options 3 and 4 are probably better than 1 or 2. They might aleviate both Jonathan and my concerns with other mechanisms. I'm not decided on if I prefer 3 or 4. I have a slight preference for 4, because 3 could be a little ambiguous. 4 would allow you to specify TLS on the last hop, but allow for both sip and sips end-to-end (useful for sip-outbound for example). Any opinions? Jonathan? Others? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 19 15:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAzF-0006px-O2; Fri, 19 May 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAz6-0006ng-2J; Fri, 19 May 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAz3-0007tB-MP; Fri, 19 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k4JJo1et027421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FhAz3-00032D-Fv; Fri, 19 May 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, 19 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-answermode-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 : Requesting Answering Modes for the Session Initiation Protocol (SIP) Author(s) : D. Willis, A. Allen Filename : draft-ietf-sip-answermode-01.txt Pages : 28 Date : 2006-5-19 This document defines two SIP extension header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-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-answermode-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-answermode-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-5-19144559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-answermode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-answermode-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-19144559.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 May 19 18:05:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhD3Z-000841-Mm; Fri, 19 May 2006 18:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhD3W-00083Q-JB; Fri, 19 May 2006 18:02:46 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhD3W-0001UB-7t; Fri, 19 May 2006 18:02:46 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4JM2jRA026708; Fri, 19 May 2006 15:02:45 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4JM2jRb026707; Fri, 19 May 2006 15:02:45 -0700 Date: Fri, 19 May 2006 15:02:45 -0700 Message-Id: <200605192202.k4JM2jRb026707@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4488 on Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4488 Title: Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription Author: O. Levin Status: Standards Track Date: May 2006 Mailbox: oritl@microsoft.com Pages: 8 Characters: 17264 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-refer-with-norefersub-04.txt URL: http://www.rfc-editor.org/rfc/rfc4488.txt The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 19 20:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEss-0004V1-08; Fri, 19 May 2006 19:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEsq-0004RJ-3J for sip@ietf.org; Fri, 19 May 2006 19:59:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhEmF-0008IE-0d for sip@ietf.org; Fri, 19 May 2006 19:53:04 -0400 Received: from [192.168.1.8] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4JNs0jL010696 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 May 2006 18:54:05 -0500 In-Reply-To: <446D3E5E.4070800@opencloud.com> References: <446BFE27.4070909@opencloud.com> <5FE19E1C-71D9-4FF9-A2B3-FBD704CCC9F8@softarmor.com> <446D3E5E.4070800@opencloud.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question Date: Fri, 19 May 2006 18:52:45 -0500 To: Ben Evans X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 May 18, 2006, at 10:41 PM, Ben Evans wrote: > Dean Willis wrote: >> >> On May 17, 2006, at 11:55 PM, Ben Evans wrote: >>> [...] >>> Because the ACK's Request-URI contains UA1's contact URI, not the >>> AOR, the proxy would normally not do a location service lookup (the >>> contact URI is a physical IP address/port). So how does the proxy >>> obtain the flow information from the location service so that >>> it can >>> send the ACK (and any future mid-dialog requests) on the correct >>> flow? What am I missing? >> >> >> My theory is that the proxy should use the "double record routing >> trick". As such, it inserts two R-R values. The first identifies the >> interface and flow binding for UA1, and the second identifies the >> interface as seen by UA2. >> >> When the proxy receives the ACK at step 6, it pops the first >> route (its >> interface facing UA2). It then inspects the next route to figure out >> where to send. Since this next route is also "local", it pops this >> route field, picks the flow from the information in that route >> field, >> and puts the ACK onto the flow towards UA1. >> >> We originally developed this trick to work with proxies that have >> more >> than one interface, but since the flow identifier is sort of a >> "virtual >> interface", the technique should work here. > > Thanks Dean, this worked really well. Should this technique should > be mentioned in the draft? Or maybe it is already obvious to those > in the know! Good point. Probably wouldn't hurt to mention it. Lots of people just assume people understand this, so it may not get the needed coverage. Oh Mr. Outbound Editor . . . -- 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 May 19 20:02:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEtF-0004yJ-Id; Fri, 19 May 2006 20:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEtC-0004uh-PF for sip@ietf.org; Fri, 19 May 2006 20:00:14 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhEtC-0001D9-F5 for sip@ietf.org; Fri, 19 May 2006 20:00:14 -0400 Received: from [192.168.1.8] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4K01JkH010724 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 May 2006 19:01:21 -0500 In-Reply-To: <446D3E5F.8000909@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97CE7@zrc2hxm0.corp.nortel.com> <446D3E5F.8000909@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1416E38D-E25C-484B-9E32-CC94554B2FC6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: draft-audet-sip-sips-guidelines: sip and sips contacts in Registrations Date: Fri, 19 May 2006 19:00:06 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 May 18, 2006, at 10:41 PM, Jonathan Rosenberg wrote: > . > > In this particular case, I think simplicity trumps features. I > think it is an undue burden to require two contacts just to > indicate something that should normally be permitted. I would think > that in 99.9% of the cases, a UA would be willing to accept calls > of either type. I can't see any case where it would only accept sip > and not sips. I can imagine cases (secure phone service) where it > would only accept sips. However, as Juha points out in his mail, it > can simply reject an incoming call which was received over sip. All > your proposal does is push that rejection into the network. For > what benefit? > Let's be real. 3GPP IMS clients can't deal with SIPS. But their SIP comes over a link that is arguably as-well protected as 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 May 19 20:02:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEsZ-0004MY-7R; Fri, 19 May 2006 19:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhEsW-0004Lr-21 for sip@ietf.org; Fri, 19 May 2006 19:59:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhErk-0000k8-Vz for sip@ietf.org; Fri, 19 May 2006 19:58:45 -0400 Received: from [192.168.1.8] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4JNxo4j010709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 19 May 2006 18:59:52 -0500 In-Reply-To: <446D3D6A.6060604@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9946576D-AFD4-49F2-816F-9369EA2E359E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Fri, 19 May 2006 18:58:35 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: IETF SIP List , Juha Heinanen , Francois Audet , 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 May 18, 2006, at 10:37 PM, Jonathan Rosenberg wrote: > Well, before we go and deprecate stuff let us not make the perfect > the enemy of the good. > > Yes, as Dean and others have pointed out, sips makes the assumption > that all of the proxies along the path are "good", and that they > have followed the rules about sips treatment. There is no dispute > that this does NOT protect against attacks where the proxies are > malicious and choose to ignore sips. > > However, I will assert that there are a lot of environments where > it is a reasonable assumption to make that you are trusting the > proxies. Remember, proper SIP operations depends on some level of > trust on the proxies. For most deployments, I would assert that > there is no reason that a proxy would properly perform normal SIP > processing (forwarding of requests and so on), yet not honor sips > for some malicious reason. > > So, sure - there are some number of small cases where the security > provided by sips is not sufficient because of an oddball trust > relationship with the provider. If your enviroment is not such an > environment, then sips isnt good enough and you'll need to use S/ > MIME. But S/MIME is a whole lot harder to deploy as we know, and I > don't want to make that the ONLY choice. > > *Assuming* you trust the proxies to obey sips, sips provides a lot > of nice security properties. It protects me against outside > attackers from pretty much doing anything - modifying calls, > hijacking calls, detecting call patterns, and so on. I think thats > worth preserving. > I'm thinking about this from the perspective of P2P-SIP, where one reasonable use case is to make almost every user on the net a "proxy". I'd sure like to think that they could neither see nor twiddle my signaling as it passes through them. But in any case, doing the "all compliant proxies MUST only forward SIPS request over TLS, or reject them" modifier still doesn't really help. I'd hope (haha) that any reasonable proxy would forward any traffic over a protected link if at all possible, and would only fall back to a non-protected link if thats all that was available. But the "tls only" thing prohibits IMS systems, which have reasonably robust security on the UA to P-CSCF link, from honoring SIPS requests at all -- thereby requiring use of plain SIP and degrading the effective security. -- 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 May 19 20:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhF1W-0007H8-Me; Fri, 19 May 2006 20:08:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhF1V-0007G4-Du for sip@ietf.org; Fri, 19 May 2006 20:08:49 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhF1U-0002GC-2m for sip@ietf.org; Fri, 19 May 2006 20:08:49 -0400 Received: from [192.168.1.8] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4K09YVZ010774 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 19 May 2006 19:09:52 -0500 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <51C4CF4E-C295-40EC-8CB1-1BCE7D9A4C93@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List From: Dean Willis Date: Fri, 19 May 2006 19:08:13 -0500 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Answermode draft posted X-BeenThere: sip@ietf.org X-Mailman-Version: 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 revised answermode draft, which supposedly addresses all issues (primarily stylistic) raised in WGLC has been posted. The text is available at: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-01.txt Changes consisted of correcting a number of typos and stylistic usages, and minor cleanup of the ABNF. We also added an diagram explaining the entity names (like "UAC-User") in the requirements section. No functional changes were made. Please review to make sure your issues have been addressed. -- Dean Willis Editor _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 20 01:28:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJxZ-0002ar-Uw; Sat, 20 May 2006 01:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhJxY-0002ae-Jd for sip@ietf.org; Sat, 20 May 2006 01:25:04 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhJiV-00044a-2Z for sip@ietf.org; Sat, 20 May 2006 01:09:34 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 38E771400D0; Sat, 20 May 2006 08:09:27 +0300 (EEST) Received: from rautu (anneal125.gprs.dnafinland.fi [62.78.105.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id E89A81400CA; Sat, 20 May 2006 08:09:19 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D5E95F01D4; Sat, 20 May 2006 08:09:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17518.42109.696557.418601@rautu.tutpro.com> Date: Sat, 20 May 2006 08:09:17 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <9946576D-AFD4-49F2-816F-9369EA2E359E@softarmor.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <9946576D-AFD4-49F2-816F-9369EA2E359E@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: IETF SIP List , Paul Kyzivat , 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 Dean Willis writes: > But the > "tls only" thing prohibits IMS systems, which have reasonably robust > security on the UA to P-CSCF link, from honoring SIPS requests at all > -- thereby requiring use of plain SIP and degrading the effective > security. sorry, but you have wrong mailing list. -- 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 Sun May 21 07:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhmI9-0006x3-RU; Sun, 21 May 2006 07:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhmI8-0006wF-Kx for sip@ietf.org; Sun, 21 May 2006 07:40:12 -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 1FhmI7-0008J3-7k for sip@ietf.org; Sun, 21 May 2006 07:40:12 -0400 Received: (qmail invoked by alias); 21 May 2006 11:40:10 -0000 Received: from p54984883.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.72.131] by mail.gmx.net (mp010) with SMTP; 21 May 2006 13:40:10 +0200 X-Authenticated: #29516787 Message-ID: <4470519F.60108@gmx.net> Date: Sun, 21 May 2006 13:40:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org, geopriv@ietf.org 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: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Sip] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 James Hi Brian, do you plan to put additional info into the SIP message to indicate who should consume the Location Object (explicity rather than implicit info)? Here is an example: Assume that SIP UA Alice wants to give Bob location information (via reference). Now, Alice could easily indicate that it wants Bob to resolve the reference and to process the location object. Stating this explicitly would prevent proxies to resolve it and to process the location object. 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 May 21 21:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhyr2-0003T8-2q; Sun, 21 May 2006 21:05:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhyr1-0003Sq-7b; Sun, 21 May 2006 21:05:03 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhyqz-0002Yk-Vq; Sun, 21 May 2006 21:05:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fhyqo-00079A-RS; Sun, 21 May 2006 20:04:51 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , , Date: Sun, 21 May 2006 21:04:55 -0400 Message-ID: <073101c67d3b$bfa8efe0$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: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75A In-Reply-To: <4470519F.60108@gmx.net> 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: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 no. If the location is not needed by proxies, then I would say you MUST protect it (S/MIME), or it will not be private. If you have to route on it (emergency or otherwise), then you have to send it with TLS, and the proxies can see it. Brian -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, May 21, 2006 7:40 AM To: sip@ietf.org; geopriv@ietf.org Subject: [Geopriv] Explicit Indication of Location Object Consumer Hi James Hi Brian, do you plan to put additional info into the SIP message to indicate who should consume the Location Object (explicity rather than implicit info)? Here is an example: Assume that SIP UA Alice wants to give Bob location information (via reference). Now, Alice could easily indicate that it wants Bob to resolve the reference and to process the location object. Stating this explicitly would prevent proxies to resolve it and to process the location object. Ciao Hannes _______________________________________________ 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 Sun May 21 21:13:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhyx9-0005Bm-UP; Sun, 21 May 2006 21:11:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhyx9-0005Be-7M; Sun, 21 May 2006 21:11:23 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhyx7-0002lN-V1; Sun, 21 May 2006 21:11:23 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 May 2006 20:11:35 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 21 May 2006 20:11:34 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 May 2006 20:11:34 -0500 Message-ID: From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , , Date: Sun, 21 May 2006 20:11:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 May 2006 01:11:34.0296 (UTC) FILETIME=[AAC19180:01C67D3C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <073101c67d3b$bfa8efe0$640fa8c0@cis.neustar.com> Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Explicit Indication of Location Object Consumer Thread-Index: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75AAAA7NwA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 inclined to agree with Brian here. I am not sure why a proxy would just pickout a location URI and de-reference it unless the proxy needed to use it in some way anyway. Perhaps the example is not such a good one. Hannes do you have something more concrete in mind?=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, 22 May 2006 11:05 AM > To: 'Hannes Tschofenig'; sip@ietf.org; geopriv@ietf.org > Subject: RE: [Geopriv] Explicit Indication of Location Object Consumer >=20 > I would say no. If the location is not needed by proxies, then I would > say > you MUST protect it (S/MIME), or it will not be private. >=20 > If you have to route on it (emergency or otherwise), then you have to send > it with TLS, and the proxies can see it. >=20 > Brian >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, May 21, 2006 7:40 AM > To: sip@ietf.org; geopriv@ietf.org > Subject: [Geopriv] Explicit Indication of Location Object Consumer >=20 > Hi James > Hi Brian, >=20 > do you plan to put additional info into the SIP message to indicate who > should consume the Location Object (explicity rather than implicit info)? >=20 > Here is an example: Assume that SIP UA Alice wants to give Bob location > information (via reference). Now, Alice could easily indicate that it > wants Bob to resolve the reference and to process the location object. > Stating this explicitly would prevent proxies to resolve it and to > process the location object. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 21 23:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi0td-00014I-9q; Sun, 21 May 2006 23:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi0tb-00014A-KR for sip@ietf.org; Sun, 21 May 2006 23:15:51 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi0ta-0007w9-NC for sip@ietf.org; Sun, 21 May 2006 23:15:51 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B0071205DC for ; Mon, 22 May 2006 08:44:11 +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 97468205D9 for ; Mon, 22 May 2006 08:44:11 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 08:45:41 +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: RE: [Sip] comments on draft-ietf-sip-fork-loop-fix-01 Date: Mon, 22 May 2006 08:45:41 +0530 Message-ID: <2B82DDF2CCFC3F4185C0D51A2E0A357A224BA1@blr-m2-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] comments on draft-ietf-sip-fork-loop-fix-01 Thread-Index: AcZ5GobfXQUcTCJiSl6+Iyq+lPZN5QC2Oumg From: To: X-OriginalArrivalTime: 22 May 2006 03:15:41.0834 (UTC) FILETIME=[01D5AEA0:01C67D4E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 was thinking how to reduce the impact of overhead for calculating the digest. If it is suggested as follows, I think it will reduce the overhead on normal scenarios: Proxy checks to see if its address is there in the via already.=20 If it is not there, it proceeds normally without calculating the digest and inserting Via to the outgoing request without the digest. If it is there, then it is possible that the request is looping. So, this time around, it calculates a digests and inserts and sends it along. If it is looping, the request will definitely come in again, which can be rejected. This way the impact of calculating the digest is required (reduced to a smaller percent of the sessions) only when the proxy is suspicious the request might be looping. Of course this results in the scenarios mentioned in the id to be successful in completing the first loop, but the second loop will be detected and arrested. I think this can be applicable to general loop detection, and not just fork loop fixes. I am not sure if this already has been discussed. If not, this probably can be considered to be suggested in the id. Regards, Ravi. > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Wednesday, May 17, 2006 12:25 AM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] comments on draft-ietf-sip-fork-loop-fix-01 >=20 > inline >=20 > > inline. > > > > Jeroen van Bemmel wrote: > > > >>>> These requirements and the recommendation to use the=20 > loop-detection > >>>> mechanisms from RFC 3261 make the favorable trade of=20 > exponential > >>>> message growth for work that is at worst case order=20 > n^2 as a message > >>>> crosses n proxies. Specifically, this work is order=20 > m*n where m is > >>>> the number of proxies in the path that fork the=20 > request to more than > >>>> one location. In practice, m is expected to be small. > >>> > >>> > >>> You should explain what this work is - checking each of the N via=20 > >>> headers. You also don't explicitly say that this n^2 work=20 > is spread=20 > >>> across n proxies. Its only N at any particular proxy. This is=20 > >>> important because, as I argued at the mike, I think the=20 > constant in=20 > >>> front of this is sufficiently small to be unimportant. > >>> > >> > >> I would expect that the bulk of the work is not inspecting the Via=20 > >> headers, but rather calculating the digest for=20 > distinguishing loops=20 > >> from spirals. > > > > Sure. But you only need to do that when there is a loop of=20 > any sort.=20 > > In other words, you first check to see if your address is=20 > on the Via list. > > Only if its there do you bother to check if it was a loop=20 > vs. a spiral. > > >=20 > There are 2 points at which a proxy calculates a digest: upon=20 > reception=20 > (RFC3261 16.3 point 4) and when forwarding (RFC3261 16.6=20 > point 8). You can=20 > avoid the first when there is no matching via header, and you=20 > can avoid the=20 > second when you already calculated the first, but it will have to be=20 > performed once for each passage of a request (before translation),=20 > regardless whether there is a loop or not. >=20 > > > > > >> And you're trading *potential* (typically very rare)=20 > exponential message=20 > >> growth for *guaranteed* (always, for every forked request)=20 > order n^2=20 > >> work. > > > > Well, the huge potential damage from this attack really=20 > does require this=20 > > tradeoff. I still don't think the work is that significant.=20 > Its O(N) on=20 > > each proxy and I really do think this constant is very=20 > small. Just the=20 > > time it takes to find your own address in the Via list. > > >=20 > It's not that I disagree with the necessity, just that it=20 > should be made=20 > explicit what is being traded-off here >=20 > Regards, >=20 > jeroen >=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 May 22 02:14:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi3eV-00037D-K6; Mon, 22 May 2006 02:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi3eU-00036t-TO; Mon, 22 May 2006 02:12:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi3eS-0006Nh-F2; Mon, 22 May 2006 02:12:26 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 21 May 2006 23:12:24 -0700 X-IronPort-AV: i="4.05,153,1146466800"; d="scan'208"; a="1810235831:sNHT30232332" 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/8.12.11) with ESMTP id k4M6CNQQ010273; Sun, 21 May 2006 23:12:23 -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 k4M6CNJj012662; Sun, 21 May 2006 23:12:23 -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.211); Sun, 21 May 2006 23:12:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.45]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 May 2006 23:12:22 -0700 Message-Id: <4.3.2.7.2.20060522010851.0330c910@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 May 2006 01:12:22 -0500 To: Hannes Tschofenig , sip@ietf.org, geopriv@ietf.org From: "James M. Polk" In-Reply-To: <4470519F.60108@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 May 2006 06:12:22.0882 (UTC) FILETIME=[B08D3C20:01C67D66] DKIM-Signature: a=rsa-sha1; q=dns; l=970; t=1148278343; x=1149142343; c=relaxed/simple; s=sjdkim8001; 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]=20Explicit=20Indication=20of=20Location=20Object=20Con sumer; X=v=3Dcisco.com=3B=20h=3DnD2/mpghC2KPBP2MciCF3s3D2GM=3D; b=CyeCamw1C41URuAM6FIfeLb7EhoQZtrAL85CqLw4g73kmg1SS1GWp7oLbZL5ggTSStiMqfh6 tKhAA+yEd6Berl+6jd2M7ULE7BG92MMyTdiiJHYYeEDxbPUiIE3xmcYH; Authentication-Results: sj-dkim-8.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Sip] Re: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 01:40 PM 5/21/2006 +0200, Hannes Tschofenig wrote: >Hi James >Hi Brian, > >do you plan to put additional info into the SIP message to indicate who >should consume the Location Object (explicity rather than implicit info)? Implicit is how I envision Location being in a SIP request message. A UAC needs to know that if the message needs to be routed based on Location by-value or by-reference that it does what it knows will work for/at the routing element. >Here is an example: Assume that SIP UA Alice wants to give Bob location >information (via reference). Now, Alice could easily indicate that it >wants Bob to resolve the reference and to process the location object. >Stating this explicitly would prevent proxies to resolve it and to process >the location object. > >Ciao >Hannes > > >_______________________________________________ >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 May 22 09:32:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAUH-0004f5-0z; Mon, 22 May 2006 09:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAUF-0004ex-P3 for sip@ietf.org; Mon, 22 May 2006 09:30:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiAUE-0000Gl-Dt for sip@ietf.org; Mon, 22 May 2006 09:30:19 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2006 09:30:16 -0400 X-IronPort-AV: i="4.05,156,1146456000"; d="scan'208"; a="89132999:sNHT33608332" 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 k4MDUBTX017967; Mon, 22 May 2006 09:30:16 -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.211); Mon, 22 May 2006 09:30:15 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 09:30:15 -0400 Message-ID: <4471BCE7.40807@cisco.com> Date: Mon, 22 May 2006 09:30:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> In-Reply-To: <446D3D6A.6060604@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2006 13:30:15.0778 (UTC) FILETIME=[DC6B0420:01C67DA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Jonathan Rosenberg wrote: > Well, before we go and deprecate stuff let us not make the perfect the > enemy of the good. > > Yes, as Dean and others have pointed out, sips makes the assumption that > all of the proxies along the path are "good", and that they have > followed the rules about sips treatment. There is no dispute that this > does NOT protect against attacks where the proxies are malicious and > choose to ignore sips. > > However, I will assert that there are a lot of environments where it is > a reasonable assumption to make that you are trusting the proxies. > Remember, proper SIP operations depends on some level of trust on the > proxies. For most deployments, I would assert that there is no reason > that a proxy would properly perform normal SIP processing (forwarding of > requests and so on), yet not honor sips for some malicious reason. > > So, sure - there are some number of small cases where the security > provided by sips is not sufficient because of an oddball trust > relationship with the provider. If your enviroment is not such an > environment, then sips isnt good enough and you'll need to use S/MIME. > But S/MIME is a whole lot harder to deploy as we know, and I don't want > to make that the ONLY choice. > > *Assuming* you trust the proxies to obey sips, sips provides a lot of > nice security properties. It protects me against outside attackers from > pretty much doing anything - modifying calls, hijacking calls, detecting > call patterns, and so on. I think thats worth preserving. So, what should use of SIPS promise, now can that promise be fullfilled, and what does that have to do with TLS? In HTTPS, there is a guarantee that the target possess a cert tied to the URI. The analogous property for SIPS could be that the target possess a cert for the user&domain of the URI. Is that reasonable? Probably not. A UA that has registered probably won't have a cert for itself. Alternatively, the property could be that some server on the path holds a cert for the domain. That at least should be achievable, much like SIP Identity. Then there is also an expectation of some kind of security and confidentiality for the signaling. In the case of HTTPS, TLS provides this. Because its end to end, its natural to tie the mechanism to the result. In the case of SIPS, since it typically isn't going to be e2e anyway, there isn't any great benefit to tying this goal to the mechanism. Since it is necessary to trust the intermediates to do the right thing to provide security and confidentiality, why isn't it reasonable to trust them to choose a mechanism as well? What is so special about TLS? This is reflected currently in 3261 by the option to use something other than TLS between the home proxy and the UAS. But I'm not clear why there is a restriction on the path from the UAC to the home proxy of the UAS. I think all that is important is that mechanisms that provide security and confidentiality be used, and that authority of the home proxy over the domain be validated. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 10:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBnY-0006IL-F7; Mon, 22 May 2006 10:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBnW-0006ID-S6; Mon, 22 May 2006 10:54:18 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBnV-0004SX-CW; Mon, 22 May 2006 10:54:18 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4MEs6Ua018222; Mon, 22 May 2006 16:54:06 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4MEs5Rk031326; Mon, 22 May 2006 16:54:05 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 16:53:45 +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: Mon, 22 May 2006 16:53:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Explicit Indication of Location Object Consumer Thread-Index: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75AABwUsIA= From: "Tschofenig, Hannes" To: "Brian Rosen" , "Hannes Tschofenig" , , X-OriginalArrivalTime: 22 May 2006 14:53:45.0807 (UTC) FILETIME=[86A0C5F0:01C67DAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Subject: [Sip] AW: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Brian,=20 > I would say no. If the location is not needed by proxies,=20 > then I would say > you MUST protect it (S/MIME), or it will not be private. I am less concerned about the security aspects here and more focused the protocol operation first.=20 Typically, it is good to know for a device whether it has to process the content of the message or not. =20 If you want to prevent intermediaries to inspect your location object then S/MIME might be a choice (at least on paper).=20 >=20 > If you have to route on it (emergency or otherwise), then you=20 > have to send > it with TLS, and the proxies can see it.=20 >=20 > Brian Ciao Hannes >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, May 21, 2006 7:40 AM > To: sip@ietf.org; geopriv@ietf.org > Subject: [Geopriv] Explicit Indication of Location Object Consumer >=20 > Hi James > Hi Brian, >=20 > do you plan to put additional info into the SIP message to=20 > indicate who=20 > should consume the Location Object (explicity rather than=20 > implicit info)? >=20 > Here is an example: Assume that SIP UA Alice wants to give=20 > Bob location=20 > information (via reference). Now, Alice could easily indicate that it=20 > wants Bob to resolve the reference and to process the=20 > location object.=20 > Stating this explicitly would prevent proxies to resolve it and to=20 > process the location object. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 11:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCAf-0006Xu-FQ; Mon, 22 May 2006 11:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCAd-0006Xp-NU for sip@ietf.org; Mon, 22 May 2006 11:18:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCAb-0005dc-Ch for sip@ietf.org; Mon, 22 May 2006 11:18:11 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4MFJF4V011394 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 22 May 2006 10:19:17 -0500 In-Reply-To: <17518.42109.696557.418601@rautu.tutpro.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <9946576D-AFD4-49F2-816F-9369EA2E359E@softarmor.com> <17518.42109.696557.418601@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74A34239-B7C9-45EF-9C91-DF22EFB40FE1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 10:18:00 -0500 To: Juha Heinanen X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , Paul Kyzivat , 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 May 20, 2006, at 12:09 AM, Juha Heinanen wrote: > Dean Willis writes: > >> But the >> "tls only" thing prohibits IMS systems, which have reasonably robust >> security on the UA to P-CSCF link, from honoring SIPS requests at all >> -- thereby requiring use of plain SIP and degrading the effective >> security. > > sorry, but you have wrong mailing list. > Excuse me? I suppose this is some sort of snide comment implying that we've been overrun by IMS worshippers again? If IETF makes the change proposed by Jonathan (TLS must be end to end) it will have the side-effect of reducing the effective security available when talking from "new IETF SIP systems" to "existing IMS SIP systems". This may suggest that we consider alternatives. We (the IETF) have formal relations with other bodies that consume or specs, like 3GPP. We can't go and change a specification in a way that pulls the rug under them without at least considering the implications. If you don't like it, take it up with the IESG and IAB and see if you can get the cooperation agreement retracted. -- 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 May 22 11:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCEE-00074C-3K; Mon, 22 May 2006 11:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCEC-000745-No for sip@ietf.org; Mon, 22 May 2006 11:21:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCEB-0005k1-Cc for sip@ietf.org; Mon, 22 May 2006 11:21:52 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4MFMxoZ011421 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 22 May 2006 10:23:02 -0500 In-Reply-To: <4471BCE7.40807@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <4471BCE7.40807@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 10:21:41 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.750) 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 22, 2006, at 8:30 AM, Paul Kyzivat wrote: > > > So, what should use of SIPS promise, now can that promise be > fullfilled, and what does that have to do with TLS? > > In HTTPS, there is a guarantee that the target possess a cert tied > to the URI. The analogous property for SIPS could be that the > target possess a cert for the user&domain of the URI. Is that > reasonable? Probably not. A UA that has registered probably won't > have a cert for itself. Alternatively, the property could be that > some server on the path holds a cert for the domain. That at least > should be achievable, much like SIP Identity. That second property -- that some server on the path holds a cert for the domain, is exactly the property we have now for sips as I understand it. > > Then there is also an expectation of some kind of security and > confidentiality for the signaling. In the case of HTTPS, TLS > provides this. Because its end to end, its natural to tie the > mechanism to the result. In the case of SIPS, since it typically > isn't going to be e2e anyway, there isn't any great benefit to > tying this goal to the mechanism. Since it is necessary to trust > the intermediates to do the right thing to provide security and > confidentiality, why isn't it reasonable to trust them to choose a > mechanism as well? What is so special about TLS? This is reflected > currently in 3261 by the option to use something other than TLS > between the home proxy and the UAS. But I'm not clear why there is > a restriction on the path from the UAC to the home proxy of the > UAS. I think all that is important is that mechanisms that provide > security and confidentiality be used, and that authority of the > home proxy over the domain be validated. I concur. I would still like to have a mechanism that assures end-to-end and that the UAS holds a cert for the username/domain combo, but sips: isn't currently that mechanism. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 11:32:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCMg-0003fF-E2; Mon, 22 May 2006 11:30:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCMf-0003ed-1i; Mon, 22 May 2006 11:30:37 -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 1FiBlL-0004H6-2L; Mon, 22 May 2006 10:52:03 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiBaS-0002y2-9R; Mon, 22 May 2006 10:40:50 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4MEd2MB019771; Mon, 22 May 2006 16:39:03 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4MEcxGt013360; Mon, 22 May 2006 16:39:02 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 16:38:42 +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: Mon, 22 May 2006 16:38:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Explicit Indication of Location Object Consumer Thread-Index: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75AAAA7NwAAG/KsEA== From: "Tschofenig, Hannes" To: "Winterbottom, James" , "Brian Rosen" , "Hannes Tschofenig" , , X-OriginalArrivalTime: 22 May 2006 14:38:42.0922 (UTC) FILETIME=[6C7774A0:01C67DAD] X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: [Sip] AW: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 James,=20 > I am inclined to agree with Brian here. >=20 > I am not sure why a proxy would just pickout a location URI and > de-reference it unless the proxy needed to use it in some way anyway. > Perhaps the example is not such a good one. Hannes do you=20 > have something > more concrete in mind?=20 The location conveyance draft has emergency and non-emergency applications in mind.=20 With emergency calls you want the proxy and the PSAP (as the other end of the call) to process the location objects.=20 For non-emergency applications you either might want the proxy (for location-based routing or the end host to process the LO; or even both). So, do you think there is no need to tell which entity should process it? Ciao Hannes > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, 22 May 2006 11:05 AM > > To: 'Hannes Tschofenig'; sip@ietf.org; geopriv@ietf.org > > Subject: RE: [Geopriv] Explicit Indication of Location=20 > Object Consumer > >=20 > > I would say no. If the location is not needed by proxies, then I > would > > say > > you MUST protect it (S/MIME), or it will not be private. > >=20 > > If you have to route on it (emergency or otherwise), then=20 > you have to > send > > it with TLS, and the proxies can see it. > >=20 > > Brian > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Sunday, May 21, 2006 7:40 AM > > To: sip@ietf.org; geopriv@ietf.org > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > >=20 > > Hi James > > Hi Brian, > >=20 > > do you plan to put additional info into the SIP message to indicate > who > > should consume the Location Object (explicity rather than implicit > info)? > >=20 > > Here is an example: Assume that SIP UA Alice wants to give Bob > location > > information (via reference). Now, Alice could easily=20 > indicate that it > > wants Bob to resolve the reference and to process the=20 > location object. > > Stating this explicitly would prevent proxies to resolve it and to > > process the location object. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 11:50:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCdz-0000lT-7f; Mon, 22 May 2006 11:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCdy-0000lL-Cn; Mon, 22 May 2006 11:48:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCdu-0007Fw-Qe; Mon, 22 May 2006 11:48:30 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 08:48:26 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="1810489754:sNHT86617360" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4MFmPGV017515; Mon, 22 May 2006 08:48:26 -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 k4MFmPB7011398; Mon, 22 May 2006 08:48:25 -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, 22 May 2006 08:48:25 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 08:48:24 -0700 Message-Id: <4.3.2.7.2.20060522104226.03862f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 May 2006 10:48:23 -0500 To: "Tschofenig, Hannes" , "Winterbottom, James" , "Brian Rosen" , "Hannes Tschofenig" , , From: "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 May 2006 15:48:24.0790 (UTC) FILETIME=[290DDF60:01C67DB7] DKIM-Signature: a=rsa-sha1; q=dns; l=4212; t=1148312906; x=1149176906; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20AW=3A=20[Geopriv]=20Explicit=20Indication=20of=20Location=20Obje ct=0A=20=20Consumer; X=v=3Dcisco.com=3B=20h=3DKPIw5wfAmK5PYedYP5XWX0gS74w=3D; b=nm1KRaVNvAuim9EOoZ4u6+S2fPGhub+C+rENwcH6sJw7iHAM7qBo/BNtocIHrhNO++Fd5GCO WmY3GM5jzzjK59ec3T0YLulCCkAHTRErhvybtcZ84dxO0Y5HcHL3h1wE; Authentication-Results: sj-dkim-1.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Subject: [Sip] Re: AW: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 04:38 PM 5/22/2006 +0200, Tschofenig, Hannes wrote: >Hi James, > > > I am inclined to agree with Brian here. > > > > I am not sure why a proxy would just pickout a location URI and > > de-reference it unless the proxy needed to use it in some way anyway. > > Perhaps the example is not such a good one. Hannes do you > > have something > > more concrete in mind? > >The location conveyance draft has emergency and non-emergency >applications in mind. >With emergency calls you want the proxy and the PSAP (as the other end >of the call) to process the location objects. >For non-emergency applications you either might want the proxy (for >location-based routing or the end host to process the LO; or even both). >So, do you think there is no need to tell which entity should process >it? I do not believe Alice's request message needs to have a special indication in it with "what to do" here. Let me give two scenarios: Alice dials 1-1-2, meaning she is calling for help. Her UA recognizes this and chooses to use TLS, knowing proxies cannot easily (or at all) decrypt S/MIME. Alice sends her location in an IM to Bob. She is not calling for emergency help. Her UA S/MIME encrypts the message body. If Bob then tells her he received her IM but not the associated location, Alice can do something special to her UA to (one time only probably) send her location in an IM to Bob without S/MIME. This will probably be using SIPS (i.e. TLS). Does this make sense? >Ciao >Hannes > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, 22 May 2006 11:05 AM > > > To: 'Hannes Tschofenig'; sip@ietf.org; geopriv@ietf.org > > > Subject: RE: [Geopriv] Explicit Indication of Location > > Object Consumer > > > > > > I would say no. If the location is not needed by proxies, then I > > would > > > say > > > you MUST protect it (S/MIME), or it will not be private. > > > > > > If you have to route on it (emergency or otherwise), then > > you have to > > send > > > it with TLS, and the proxies can see it. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Sunday, May 21, 2006 7:40 AM > > > To: sip@ietf.org; geopriv@ietf.org > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > Hi James > > > Hi Brian, > > > > > > do you plan to put additional info into the SIP message to indicate > > who > > > should consume the Location Object (explicity rather than implicit > > info)? > > > > > > Here is an example: Assume that SIP UA Alice wants to give Bob > > location > > > information (via reference). Now, Alice could easily > > indicate that it > > > wants Bob to resolve the reference and to process the > > location object. > > > Stating this explicitly would prevent proxies to resolve it and to > > > process the location object. > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > >_______________________________________________ >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 May 22 11:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCef-0000z2-7q; Mon, 22 May 2006 11:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCee-0000yx-L4 for sip@ietf.org; Mon, 22 May 2006 11:49:12 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCed-0007Hc-E2 for sip@ietf.org; Mon, 22 May 2006 11:49:12 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 299D86C017 for ; Mon, 22 May 2006 11:49:09 -0400 (EDT) Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips From: "Dale R. Worley" To: Sip In-Reply-To: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Mon, 22 May 2006 11:49:08 -0400 Message-Id: <1148312948.13541.9.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 admit I'm late to this discussion, but it seems to me that there is a reasonable purpose to which sips can be put: Provide assurance of a reasonable level of security between the caller and the callee, unless one of the servers under control of either the caller or the callee (or their agents, or organizations delegating their domain names or certifying their certificates) has been subverted. Specifically, it protects against passive packet sniffing to, let us say, the 40-bit key level. This seems to me to a minimal definition of a practically useful level of security of this sort, and I can envision it being implemented, though I can't enumerate all the details, and I can see the mechanism activated by using a sips: request-URI. But I can't see how security could be established in the reverse direction, how the callee could have assurance that the call originated from the From: URI. And without that, I can't see how we could describe what the sips mechanism guarantees in a way that is strong enough to be practically useful, as the callee wouldn't know the set of server that it is trusting. But perhaps someone else has a solution to that problem. 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 May 22 11:54:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCiL-0004Lq-9e; Mon, 22 May 2006 11:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCiJ-0004In-7d; Mon, 22 May 2006 11:52:59 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCiG-0007Qp-SM; Mon, 22 May 2006 11:52:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FiCi7-00067U-HO; Mon, 22 May 2006 10:52:48 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" , , Date: Mon, 22 May 2006 11:52:49 -0400 Message-ID: <07e801c67db7$c98bb020$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: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75AABwUsIAAAs1yUA== In-Reply-To: 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: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 see this as a problem. Let's take the non-emergency case. If I call take-out@pizza-hut.com, and I want location based routing, I put my location header in the call, and send the call with TLS. My outbound proxy will properly ignore it. The pizza-hut domain is the one that wants to do location based routing, it will get the location and send it off. I don't need to tell it to do that. I could imagine a generic location based routing proxy, but I would not think we would want to mark the location header as the way to get it invoked; we need something else (directly, or indirectly, a Route header) to do that. If I want the endpoint to get it, then I protect it with S/MIME and no proxy sees it. Brian -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Monday, May 22, 2006 10:54 AM To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer Hi Brian, > I would say no. If the location is not needed by proxies, > then I would say > you MUST protect it (S/MIME), or it will not be private. I am less concerned about the security aspects here and more focused the protocol operation first. Typically, it is good to know for a device whether it has to process the content of the message or not. If you want to prevent intermediaries to inspect your location object then S/MIME might be a choice (at least on paper). > > If you have to route on it (emergency or otherwise), then you > have to send > it with TLS, and the proxies can see it. > > Brian Ciao Hannes > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, May 21, 2006 7:40 AM > To: sip@ietf.org; geopriv@ietf.org > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > Hi James > Hi Brian, > > do you plan to put additional info into the SIP message to > indicate who > should consume the Location Object (explicity rather than > implicit info)? > > Here is an example: Assume that SIP UA Alice wants to give > Bob location > information (via reference). Now, Alice could easily indicate that it > wants Bob to resolve the reference and to process the > location object. > Stating this explicitly would prevent proxies to resolve it and to > process the location object. > > Ciao > Hannes > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > 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 May 22 12:14:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD1E-0002q4-5K; Mon, 22 May 2006 12:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD1D-0002nN-A4 for sip@ietf.org; Mon, 22 May 2006 12:12:31 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD1B-00084i-QO for sip@ietf.org; Mon, 22 May 2006 12:12:31 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4MGCSFT025559; Mon, 22 May 2006 11:12: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 k4MGCS323167; Mon, 22 May 2006 11:12:28 -0500 (CDT) Message-ID: <4471E2EC.7070101@lucent.com> Date: Mon, 22 May 2006 11:12:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <4471BCE7.40807@cisco.com> <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> In-Reply-To: <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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="===============1883689264==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1883689264== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080302070309030702020802" This is a cryptographically signed message in MIME format. --------------ms080302070309030702020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dean Willis wrote: [...] > That second property -- that some server on the path holds a cert for > the domain, is exactly the property we have now for sips as I > understand it. [...] > I would still like to have a mechanism that assures end-to-end and that > the UAS holds a cert for the username/domain combo, but sips: isn't > currently that mechanism. I have been capturing the traffic on this thread to summarize in an updated sip-tls-use draft. Besides the core meaning of sips itself (which Francois' draft is handling), a fair amount of traffic has been dedicated to the general drawbacks of using TLS in SIP, why the same drawbacks may not exist for IMS, etc. I will issue a new revision of the draft incorporating these discussions before the Montreal IETF. 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) --------------ms080302070309030702020802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjIxNjEyMjhaMCMGCSqGSIb3DQEJ BDEWBBSwrCTGsHYiMjBe1PJioSy+WxIWXjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGApDtssE1u9i3+jU65WYqDi6Gp7cgvM4zbrnvSeN4lXknUCQ+5rqoT AQzoZvW6PnUI3j2dwdS/UCwo05aU0R/buT5CcxIKG/hC8lEpu8flt5hlebn7a3sPT2RqQvyV Y4fsG52DzvfA4ERNHZ/dsGW6eI/vKKCJh+QCZof6+T4JtsQAAAAAAAA= --------------ms080302070309030702020802-- --===============1883689264== 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 --===============1883689264==-- From sip-bounces@ietf.org Mon May 22 12:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDfQ-000243-AN; Mon, 22 May 2006 12:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDfO-00023v-IN; Mon, 22 May 2006 12:54:02 -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 1FiDfM-0001G6-5b; Mon, 22 May 2006 12:54:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 22 May 2006 09:49:05 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="323103628:sNHT25592145198" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4MGn5id003616; Mon, 22 May 2006 09:49:05 -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 k4MGn4Hq009573; Mon, 22 May 2006 09:49:05 -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, 22 May 2006 09:49:05 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 09:49:04 -0700 Message-Id: <4.3.2.7.2.20060522114731.03593ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 May 2006 11:49:03 -0500 To: "Brian Rosen" , "'Tschofenig, Hannes'" , "'Hannes Tschofenig'" , , From: "James M. Polk" In-Reply-To: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 May 2006 16:49:04.0587 (UTC) FILETIME=[A28AD1B0:01C67DBF] DKIM-Signature: a=rsa-sha1; q=dns; l=3276; t=1148316545; x=1149180545; c=relaxed/simple; s=sjdkim4001; 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]=20Explicit=20Indication=20of=20Location=20Object=20Con sumer; X=v=3Dcisco.com=3B=20h=3DIvJNWI/vaUJzVdAJMjWlCgWB9Vs=3D; b=qv8wPY+x2PZNFFwLvp7WX3iEcACQdmr+xMMK9jEHZshkcpRUC5q7c2bmhRkvZwsQmwj6/ix+ j+ui8wW/QFWhdGXNQx8VlzSE3sTHiu+XHLW4lH3Mb3SH3mBpY26z5ykx; Authentication-Results: sj-dkim-4.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 - this discussion REEEEALLY needs to be on the SIP list only - as that WG owns this topic (SIP-Location). I'm not getting cross-posts from that list. I'm only getting the Geopriv posts. At 11:52 AM 5/22/2006 -0400, Brian Rosen wrote: >I don't see this as a problem. > >Let's take the non-emergency case. > >If I call take-out@pizza-hut.com, and I want location based routing, I put >my location header in the call, and send the call with TLS. My outbound >proxy will properly ignore it. The pizza-hut domain is the one that wants >to do location based routing, it will get the location and send it off. I >don't need to tell it to do that. I could imagine a generic location based >routing proxy, but I would not think we would want to mark the location >header as the way to get it invoked; we need something else (directly, or >indirectly, a Route header) to do that. > >If I want the endpoint to get it, then I protect it with S/MIME and no proxy >sees it. > >Brian > >-----Original Message----- >From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >Sent: Monday, May 22, 2006 10:54 AM >To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org >Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > >Hi Brian, > > > I would say no. If the location is not needed by proxies, > > then I would say > > you MUST protect it (S/MIME), or it will not be private. >I am less concerned about the security aspects here and more focused the >protocol operation first. >Typically, it is good to know for a device whether it has to process the >content of the message or not. > >If you want to prevent intermediaries to inspect your location object >then S/MIME might be a choice (at least on paper). > > > > > If you have to route on it (emergency or otherwise), then you > > have to send > > it with TLS, and the proxies can see it. > > > > Brian > >Ciao >Hannes > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Sunday, May 21, 2006 7:40 AM > > To: sip@ietf.org; geopriv@ietf.org > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > Hi James > > Hi Brian, > > > > do you plan to put additional info into the SIP message to > > indicate who > > should consume the Location Object (explicity rather than > > implicit info)? > > > > Here is an example: Assume that SIP UA Alice wants to give > > Bob location > > information (via reference). Now, Alice could easily indicate that it > > wants Bob to resolve the reference and to process the > > location object. > > Stating this explicitly would prevent proxies to resolve it and to > > process the location object. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > >_______________________________________________ >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 May 22 13:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEQG-0001sc-Nm; Mon, 22 May 2006 13:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEQF-0001sS-VP for sip@ietf.org; Mon, 22 May 2006 13:42:27 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCUQ-0006Xr-Fy for sip@ietf.org; Mon, 22 May 2006 11:38:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiCOI-0003bF-4V for sip@ietf.org; Mon, 22 May 2006 11:32:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 08:32:17 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="1810478422:sNHT33293494" 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/8.12.11) with ESMTP id k4MFWHdt016971; Mon, 22 May 2006 08:32:17 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4MFWGJj025478; Mon, 22 May 2006 08:32:16 -0700 (PDT) Received: from [192.168.1.2] ([10.21.153.109]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 08:32:16 -0700 In-Reply-To: <31529C1D0F94F24989CBC1BCDF3C04970818BE86@S4DE8PSAAGT.blf.telekom.de> References: <31529C1D0F94F24989CBC1BCDF3C04970818BE86@S4DE8PSAAGT.blf.telekom.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3228B6B6-1E18-4401-9D00-9B231050673F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: AW: [Sip] Connected-identity and changing the To header field ina response Date: Mon, 22 May 2006 08:32:23 -0700 To: "Jesske, R" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 May 2006 15:32:16.0750 (UTC) FILETIME=[E80EB0E0:01C67DB4] DKIM-Signature: a=rsa-sha1; q=dns; l=373; t=1148311937; x=1149175937; c=relaxed/simple; s=sjdkim6001; 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=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20the=20To=2 0header=20field=20ina=20response; X=v=3Dcisco.com=3B=20h=3DdcuLsAY/jx6kzqFY3/r7t9ZLRqs=3D; b=gm1Jy7avFw3a0VhgF76nT6T6AAmL1252J+WVNpYXGtr6Kt2+9JWfKgsTNWScqBYseWHXmObB 01iNincqLi0dloGIaZK9cRP0ygdi2N13NNDhpExkS28DTsOFaJpBxqJm; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip@ietf.org, John Elwell , Roland Jesske , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 16, 2006, at 7:07 AM, Jesske, R wrote: > John, > it is that we don't can get an connected identity within the final > response of the initial INVITE. > Your draft proposes a mid dialog request for getting this information. > That is not usable for the TIP service. I think this is part of what I am not understanding. What is the requirement here? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 22 14:19:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEyC-0008H3-6W; Mon, 22 May 2006 14:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEyA-0008Ga-Qt for sip@ietf.org; Mon, 22 May 2006 14:17:30 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEy9-0005DT-BQ for sip@ietf.org; Mon, 22 May 2006 14:17:30 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4MIFWqQ006807; Mon, 22 May 2006 21:17:27 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 21:17:18 +0300 Received: from [10.162.252.52] ([10.162.252.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 22 May 2006 21:17:18 +0300 Message-ID: <4472002D.6070400@nokia.com> Date: Mon, 22 May 2006 21:17:17 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Dale R. Worley" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> In-Reply-To: <1148312948.13541.9.camel@niagra.pingtel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2006 18:17:18.0895 (UTC) FILETIME=[F6321BF0:01C67DCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 ext Dale R. Worley wrote: > I admit I'm late to this discussion, but it seems to me that there is a > reasonable purpose to which sips can be put: > > Provide assurance of a reasonable level of security between the caller > and the callee, unless one of the servers under control of either the > caller or the callee (or their agents, or organizations delegating their > domain names or certifying their certificates) has been subverted. But what is reasonable here anyway? Is it something that reasonably allows me to show to a user a lock icon in a call dialog? I don't think it is. At least not in the same way a lock icon is used in a browser. (This is, even if trust for the domain's cert was achieved via leap-of-faith, it's still secure.) When would a user choose to use sips instead of sip? I can't think of a usage where the assurance given by sips alone would meet the lock icon test; however, TLS is usable in all of them. (For example, I read my personal email over imaps, even though I'm fully aware none (or very few) of the email is sent via TLS). So given that sips as opposed to sip is above all else a strong indication to the *human* user about security, anything less than e2e is not going to cut it. So it doesn't matter how each hop of a hop-by-hop path is secured, it's still not lockworthy for me. To make sips really useful (again thinking of the lock icon here), and given *real* security for a call requires that the media streams are secure, then if anything, sips should mean secure media must be used. But then that requires a whole lot more than requiring a specific transport between SIP nodes. 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 May 22 14:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiF7Y-0002om-P9; Mon, 22 May 2006 14:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiF7X-0002oe-AR for sip@ietf.org; Mon, 22 May 2006 14:27:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiF7U-0005Z1-Uj for sip@ietf.org; Mon, 22 May 2006 14:27:11 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 May 2006 11:27:09 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="323120595:sNHT30794160" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4MIR8q7029325; Mon, 22 May 2006 11:27:08 -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 k4MIR8Hc003618; Mon, 22 May 2006 11:27:08 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn1-710.cisco.com [10.21.98.198]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4MIOIIc021930; Mon, 22 May 2006 11:24:19 -0700 Message-ID: <44720282.8090705@cisco.com> Date: Mon, 22 May 2006 11:27:14 -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: Aki Niemi Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> In-Reply-To: <4472002D.6070400@nokia.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=2572; t=1148322428; x=1149186428; c=relaxed/simple; s=sjdkim3001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=EuKzb1PVyFDMaSr10omrJVHB3Fo0ezTL0dQiZwSDQIZAHtoUbuHsI5Xe6viOfaEVwMGYYYfy Q1JVtHnIE0Pbvgh6F6B1ZWCHW44EYwzClgb6jjbluGawXGUgU6VQtqRF; X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: >ext Dale R. Worley wrote: > > >>I admit I'm late to this discussion, but it seems to me that there is a >>reasonable purpose to which sips can be put: >> >>Provide assurance of a reasonable level of security between the caller >>and the callee, unless one of the servers under control of either the >>caller or the callee (or their agents, or organizations delegating their >>domain names or certifying their certificates) has been subverted. >> >> > >But what is reasonable here anyway? Is it something that reasonably >allows me to show to a user a lock icon in a call dialog? I don't think >it is. At least not in the same way a lock icon is used in a browser. >(This is, even if trust for the domain's cert was achieved via >leap-of-faith, it's still secure.) > >When would a user choose to use sips instead of sip? I can't think of a >usage where the assurance given by sips alone would meet the lock icon >test; however, TLS is usable in all of them. (For example, I read my >personal email over imaps, even though I'm fully aware none (or very >few) of the email is sent via TLS). > > I'm with you so far, but: >So given that sips as opposed to sip is above all else a strong >indication to the *human* user about security, anything less than e2e is >not going to cut it. So it doesn't matter how each hop of a hop-by-hop >path is secured, it's still not lockworthy for me. > > Is it really intended for _direct_ human consumption? I sure hope not. >To make sips really useful (again thinking of the lock icon here), and >given *real* security for a call requires that the media streams are >secure, then if anything, sips should mean secure media must be used. >But then that requires a whole lot more than requiring a specific >transport between SIP nodes. > > I don't really think this follows: the decision to put up the "lock" icon could and probably should weigh a lot of factors, and it's not always going to yeild the same result for all situtations. For example, when starting a "secure" session for, oh say, the Kremlin to the Whitehouse, I'm pretty sure that nothing short of S/MIME is going to do. Mike >Cheers, >Aki > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 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 1FiFSv-0002gm-D9; Mon, 22 May 2006 14:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFSj-0002ew-4u for sip@ietf.org; Mon, 22 May 2006 14:49:05 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFSh-0006ZK-Rr for sip@ietf.org; Mon, 22 May 2006 14:49:05 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4MImwRF019699; Mon, 22 May 2006 13:48:58 -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 k4MImw317845; Mon, 22 May 2006 13:48:58 -0500 (CDT) Message-ID: <4472079B.6090603@lucent.com> Date: Mon, 22 May 2006 13:48:59 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <4471BCE7.40807@cisco.com> <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> In-Reply-To: <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On May 22, 2006, at 8:30 AM, Paul Kyzivat wrote: >> >> So, what should use of SIPS promise, now can that promise be >> fullfilled, and what does that have to do with TLS? >> >> In HTTPS, there is a guarantee that the target possess a cert tied >> to the URI. The analogous property for SIPS could be that the >> target possess a cert for the user&domain of the URI. Is that >> reasonable? Probably not. A UA that has registered probably won't >> have a cert for itself. Alternatively, the property could be that >> some server on the path holds a cert for the domain. That at least >> should be achievable, much like SIP Identity. > > That second property -- that some server on the path holds a cert for > the domain, is exactly the property we have now for sips as I > understand it. Quite so. At the Dallas IETF, Derek and I had a sidebar conversation on TLS and SIP where he mentioned that we even have cases where outbound is used to pin a sips URI without the UA behind the proxy having a cert. > But in any case, doing the "all compliant proxies MUST only forward > SIPS request over TLS, or reject them" modifier still doesn't really > help. [...] But the "tls only" thing prohibits IMS systems, which > have reasonably robust security on the UA to P-CSCF link, from > honoring SIPS requests at all -- thereby requiring use of plain SIP > and degrading the effective security. This is interesting; so you are in favor of keeping the last hop behavior as specified in Section 26.2.2 of rfc3261? But I don't see the problem if on a P-CSCF -> UA link the security property is downgraded to sip; the link is protected through IPSec anyway. Degrading the security property from sips to sip on the UA -> P-CSCF link seems more of a concern, though. Thanks, - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 15:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFu9-0005aI-CB; Mon, 22 May 2006 15:17:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFu7-0005aD-W0 for sip@ietf.org; Mon, 22 May 2006 15:17:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFu2-0007sO-Jh for sip@ietf.org; Mon, 22 May 2006 15:17:23 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 12:17:18 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280799032:sNHT33640160" 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/8.12.11) with ESMTP id k4MJHHHA028532; Mon, 22 May 2006 12:17:17 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4MJHHJj017415; Mon, 22 May 2006 12:17:17 -0700 (PDT) Received: from [192.168.1.2] ([10.21.153.109]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 12:17:17 -0700 In-Reply-To: <446A2FF1.6020807@cisco.com> References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Mon, 22 May 2006 12:17:15 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 May 2006 19:17:17.0563 (UTC) FILETIME=[572B44B0:01C67DD4] DKIM-Signature: a=rsa-sha1; q=dns; l=2840; t=1148325437; x=1149189437; c=relaxed/simple; s=sjdkim5001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3DwUQdvhawa4bCU3L5RVZDcy/QkEc=3D; b=WGeq2ipsCwcwGIs/nT400UUkvMQ5gH2ic4Z1AQio1DywjMcixolsJluC5Oc1LxrOZoU2Io80 pdmXk0KCJ77oTcfNSJK5x7r7CcKXLxYIz45g8CCNCYJ/c/VVx/aPZHfM; 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: d8ae4fd88fcaf47c1a71c804d04f413d 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 This is clearly a bug in the spec. Would it be possible for the chairs to drive this to WG consensus before or during next meeting, get someone to file an errata, and then I will ask for IESG to review and get IANA updated to match the errata. Sounds like a reasonable plan? Cullen On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote: > I'd suggest that it probably should be standards track. URI > parameters are a bigger deal than headers, I think, since they are > really making changes to the fundamental SIP addressing > architecture. I don't think that is something we want everyone doing. > > -Jonathan R. > > Cullen Jennings wrote: > >> On May 9, 2006, at 8:54 PM, Dean Willis wrote: >>> >>> RFC 3969 defines the registry for SIP/SIPS URI parameters. >>> >>> It currently says: >>> >>> 4.2. Registration Policy for SIP and SIPS URI Parameters >>> >>> As per the terminology in RFC 2434 [4], the registration >>> policy for >>> SIP and SIPS URI parameters shall be "Specification Required". >>> >>> For the purposes of this registry, the parameter for which IANA >>> registration is requested MUST be defined by a standards-track >>> RFC. >>> >>> >>> Note that the above two paragraphs seem to be self >>> contradictory. "Specification Required" means 3GPP and >>> recognized bodies can define parameters by publishing >>> specifications. But"Standards Track RFC" means only IETF can do >>> so, and it has to be done with an IETF- consensus standards-track >>> document. >>> >>> Note that the IANA registry currently says: >>> >>> >>> SIP/SIPS URI Parameters RFC3969 Specification Required >>> >>> SIP/SIPS URI Parameters - per [RFC3969] >>> (New registrations are via Specification Required) >>> >>> This means that the current IANA policy for this registry is >>> "Specification Required". >>> >>> >>> Which did we mean? >> We might want to check with Allison on history of this but my >> vague recollection was last time we discussed this, we decided we >> meant "Standards Track". I forget the details and may be totally >> wrong. >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP 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 May 22 15:32:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiG6R-0006sB-Aq; Mon, 22 May 2006 15:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiG6P-0006s6-RV for sip@ietf.org; Mon, 22 May 2006 15:30:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiG6N-0008M3-HN for sip@ietf.org; Mon, 22 May 2006 15:30:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2006 12:30:03 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="28637081:sNHT22580408" 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 k4MJU2TL014168; Mon, 22 May 2006 15:30:02 -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.211); Mon, 22 May 2006 15:30:01 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 15:30:01 -0400 Message-ID: <44721139.9020701@cisco.com> Date: Mon, 22 May 2006 15:30:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> In-Reply-To: <44720282.8090705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2006 19:30:01.0616 (UTC) FILETIME=[1E948100:01C67DD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael Thomas wrote: > Aki Niemi wrote: > >> ext Dale R. Worley wrote: >> >> >>> I admit I'm late to this discussion, but it seems to me that there is a >>> reasonable purpose to which sips can be put: >>> >>> Provide assurance of a reasonable level of security between the caller >>> and the callee, unless one of the servers under control of either the >>> caller or the callee (or their agents, or organizations delegating their >>> domain names or certifying their certificates) has been subverted. >>> >> >> But what is reasonable here anyway? Is it something that reasonably >> allows me to show to a user a lock icon in a call dialog? I don't think >> it is. At least not in the same way a lock icon is used in a browser. >> (This is, even if trust for the domain's cert was achieved via >> leap-of-faith, it's still secure.) >> >> When would a user choose to use sips instead of sip? I can't think of a >> usage where the assurance given by sips alone would meet the lock icon >> test; however, TLS is usable in all of them. (For example, I read my >> personal email over imaps, even though I'm fully aware none (or very >> few) of the email is sent via TLS). >> >> > > I'm with you so far, but: > >> So given that sips as opposed to sip is above all else a strong >> indication to the *human* user about security, anything less than e2e is >> not going to cut it. So it doesn't matter how each hop of a hop-by-hop >> path is secured, it's still not lockworthy for me. >> >> > > Is it really intended for _direct_ human consumption? I sure hope not. Probably not. It is indeed the hypothetical lock icon on the phone that is really going to matter. >> To make sips really useful (again thinking of the lock icon here), and >> given *real* security for a call requires that the media streams are >> secure, then if anything, sips should mean secure media must be used. >> But then that requires a whole lot more than requiring a specific >> transport between SIP nodes. > > I don't really think this follows: the decision to put up the "lock" > icon could > and probably should weigh a lot of factors, and it's not always going to > yeild > the same result for all situtations. For example, when starting a > "secure" session > for, oh say, the Kremlin to the Whitehouse, I'm pretty sure that nothing > short > of S/MIME is going to do. I suspect that the lock icon will be driven by policy in the UAs, and that in many cases will be coupled to the service provider policies. In general nobody seems to know how to deploy a practical system that uses S/MIME as the mechanism for this. Some people (myself included) had been thinking (falsely it apparently turns out) that SIPS was at least part of the mechanism for providing that lock icon. (Also need media security, perhaps using sdescriptions over the secure signaling path.) I think we need *some* mechanism that can provide the lock icon in plausible deployments. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 15:51:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPC-0001wi-LB; Mon, 22 May 2006 15:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGPB-0001wd-8x for sip@ietf.org; Mon, 22 May 2006 15:49:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiGPA-0000xC-0J for sip@ietf.org; Mon, 22 May 2006 15:49:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 12:49:28 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280818510:sNHT34089440" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4MJnRxS015383; Mon, 22 May 2006 12:49:27 -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 k4MJnRB7010019; Mon, 22 May 2006 12:49:27 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn1-710.cisco.com [10.21.98.198]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4MJkbSq023738; Mon, 22 May 2006 12:46:37 -0700 Message-ID: <447215CD.1030801@cisco.com> Date: Mon, 22 May 2006 12:49:33 -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] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> In-Reply-To: <44721139.9020701@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=911; t=1148327367; x=1149191367; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DyzsSCxLWm96E0P7v4EIroZxlUvU=3D; b=eo4qrKta0AY2kbq799UewdBAJUDuLdVY1lsYHo/dgGlLFsANWSrzDe37iJFU3xFTXEfUBbmS h64emnddlc2anaHKbTfq1zjtbCJmy4+sA1fN2nFWMY3mY27SKsHE1yDz; X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > In general nobody seems to know how to deploy a practical system that > uses S/MIME as the mechanism for this. Some people (myself included) > had been thinking (falsely it apparently turns out) that SIPS was at > least part of the mechanism for providing that lock icon. (Also need > media security, perhaps using sdescriptions over the secure signaling > path.) I'm afraid that this is "elephants all the way down". It's been a while since I looked but AFAIK sdescriptions doesn't scale any better to clients, the basic problem being interdomain credentials which scale to users in _any_ form. > I think we need *some* mechanism that can provide the lock icon in > plausible deployments. Why? Seriously. Maybe the fallacy is that we're striving for a binary value when reality wants it to be a scale. Or even that we show people at 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 Mon May 22 16:04:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGbf-0004PW-9F; Mon, 22 May 2006 16:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiGbd-0004Og-Uq for sip@ietf.org; Mon, 22 May 2006 16:02:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiGbc-0001y5-G0 for sip@ietf.org; Mon, 22 May 2006 16:02:21 -0400 Received: (qmail invoked by alias); 22 May 2006 19:55:38 -0000 Received: from p54984582.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.69.130] by mail.gmx.net (mp037) with SMTP; 22 May 2006 21:55:38 +0200 X-Authenticated: #29516787 Message-ID: <4472173D.3090801@gmx.net> Date: Mon, 22 May 2006 21:55:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen References: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> In-Reply-To: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Brian, Brian Rosen wrote: > I don't see this as a problem. > > Let's take the non-emergency case. > > If I call take-out@pizza-hut.com, and I want location based routing, I put > my location header in the call, and send the call with TLS. My outbound > proxy will properly ignore it. Why do you expect the outbound proxy to ignore it? The pizza-hut domain is the one that wants > to do location based routing, it will get the location and send it off. I > don't need to tell it to do that. I could imagine a generic location based > routing proxy, but I would not think we would want to mark the location > header as the way to get it invoked; we need something else (directly, or > indirectly, a Route header) to do that. > > If I want the endpoint to get it, then I protect it with S/MIME and no proxy > sees it. I can buy the remark by James that you would put the location object into the body to tell the proxy not to look at it. S/MIME is nice; but maybe it is not always available. Ciao Hannes > > Brian > > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Monday, May 22, 2006 10:54 AM > To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > Hi Brian, > > >>I would say no. If the location is not needed by proxies, >>then I would say >>you MUST protect it (S/MIME), or it will not be private. > > I am less concerned about the security aspects here and more focused the > protocol operation first. > Typically, it is good to know for a device whether it has to process the > content of the message or not. > > If you want to prevent intermediaries to inspect your location object > then S/MIME might be a choice (at least on paper). > > >>If you have to route on it (emergency or otherwise), then you >>have to send >>it with TLS, and the proxies can see it. >> >>Brian > > > Ciao > Hannes > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Sunday, May 21, 2006 7:40 AM >>To: sip@ietf.org; geopriv@ietf.org >>Subject: [Geopriv] Explicit Indication of Location Object Consumer >> >>Hi James >>Hi Brian, >> >>do you plan to put additional info into the SIP message to >>indicate who >>should consume the Location Object (explicity rather than >>implicit info)? >> >>Here is an example: Assume that SIP UA Alice wants to give >>Bob location >>information (via reference). Now, Alice could easily indicate that it >>wants Bob to resolve the reference and to process the >>location object. >>Stating this explicitly would prevent proxies to resolve it and to >>process the location object. >> >>Ciao >>Hannes >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv >> >> >>_______________________________________________ >>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 May 22 16:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiH94-0001TU-Vt; Mon, 22 May 2006 16:36:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiH93-0001TM-5B; Mon, 22 May 2006 16:36:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiH90-0003dK-RY; Mon, 22 May 2006 16:36:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 13:36:50 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="280852971:sNHT35581060" 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/8.12.11) with ESMTP id k4MKaoHf008801; Mon, 22 May 2006 13:36:50 -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 k4MKaWsV000312; Mon, 22 May 2006 13:36:50 -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, 22 May 2006 13:36:48 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 13:36:47 -0700 Message-Id: <4.3.2.7.2.20060522153128.035f4380@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 May 2006 15:36:46 -0500 To: Hannes Tschofenig , Brian Rosen From: "James M. Polk" In-Reply-To: <4472173D.3090801@gmx.net> References: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 22 May 2006 20:36:47.0743 (UTC) FILETIME=[726AF8F0:01C67DDF] DKIM-Signature: a=rsa-sha1; q=dns; l=1236; t=1148330210; x=1149194210; c=relaxed/simple; s=sjdkim5001; 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]=20Explicit=20Indication=20of=20Location=20Object=20Con sumer; X=v=3Dcisco.com=3B=20h=3DnD2/mpghC2KPBP2MciCF3s3D2GM=3D; b=TMBtNADW2wWSfVRq7XWvqhX4JQuAbz0PNBGixfWH9YDXL78feh3S/PRvacwOuYi9gxBd5AIM yeJwnCQ4+eIDP3UsU5KiuAlA/66mv9EXJQGmq0GnWnvkt7wShPqxVoRI; 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: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] Re: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 09:55 PM 5/22/2006 +0200, Hannes Tschofenig wrote: >Hi Brian, > >Brian Rosen wrote: > > The pizza-hut domain is the one that wants >>to do location based routing, it will get the location and send it off. I >>don't need to tell it to do that. I could imagine a generic location based >>routing proxy, but I would not think we would want to mark the location >>header as the way to get it invoked; we need something else (directly, or >>indirectly, a Route header) to do that. >>If I want the endpoint to get it, then I protect it with S/MIME and no proxy >>sees it. > >I can buy the remark by James that you would put the location object into >the body to tell the proxy not to look at it. There are more and more B2BUAs and S-CSCFs that allow inspection and alteration of message bodies. I assume these are transparent to the UAC, so making this assumption of "in the message body means proxies don't look at it" is perhaps not going to get what you seem to want. Do you want a feature-tag (?) in the Location header to indidcate which type of SIP element should look for location in a particular message? >S/MIME is nice; but maybe it is not always available. agreed >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 Mon May 22 17:49:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIEp-0007nw-Id; Mon, 22 May 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 1FiIEo-0007nb-Aw; Mon, 22 May 2006 17:46:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIEn-0008F5-34; Mon, 22 May 2006 17:46:54 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2006 14:46:53 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208"; a="28651988:sNHT22430900" 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 k4MLknTR015706; Mon, 22 May 2006 17:46:52 -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.211); Mon, 22 May 2006 17:46:49 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 17:46:49 -0400 Message-ID: <44723149.3030203@cisco.com> Date: Mon, 22 May 2006 17:46:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Sip] Re: [Geopriv] Explicit Indication of Location Object Consumer References: <07e801c67db7$c98bb020$640fa8c0@cis.neustar.com> <4472173D.3090801@gmx.net> In-Reply-To: <4472173D.3090801@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2006 21:46:49.0601 (UTC) FILETIME=[3AEB9F10:01C67DE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sip@ietf.org, 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 Hannes Tschofenig wrote: > Hi Brian, > > Brian Rosen wrote: >> I don't see this as a problem. >> Let's take the non-emergency case. >> >> If I call take-out@pizza-hut.com, and I want location based routing, I >> put >> my location header in the call, and send the call with TLS. My outbound >> proxy will properly ignore it. > > Why do you expect the outbound proxy to ignore it? As far as I can tell there is nothing that says a proxy *should* look at the location for routing. For a proxy that doesn't manage the domain of the R-URI, 3263 applies. While I suppose a proxy could use the location to route somewhere *first*, that wouldn't change the obligation to route to someplace belonging to the target domain. Once you reach a proxy for the target domain, *it* may replace the R-URI, and the policy for doing so is up to it. So using the location at that point is entirely reasonable. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 18:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIQt-0002qk-Lx; Mon, 22 May 2006 17:59:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIQs-0002qP-BX; Mon, 22 May 2006 17:59:22 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIQq-0000EX-UL; Mon, 22 May 2006 17:59:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FiIQc-0006F8-UT; Mon, 22 May 2006 16:59:09 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Date: Mon, 22 May 2006 17:59:10 -0400 Message-ID: <08a301c67dea$f8ac2b90$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: AcZ92bCMsiUhFPsiSvGdOo9SOPUHGgADOoQw In-Reply-To: <4472173D.3090801@gmx.net> 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: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org, geopriv@ietf.org Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 outbound proxy doesn't do location based routing (although some may do so for emergency calls). It will ignore it, because it doesn't do location based routing, as will any proxy in the path. The one that does (pizza-hut.com) knows to do location based routing, because that is what it's supposed to do to resolve take-out@pizza-hut.com. I'm trying to stay within the geopriv rules. They require that the LO be protected from unauthorized entities learning the location. With SIP, we have hop-by-hop security mechanisms (TLS) and we have end-to-end mechanisms (S/MIME). If I want routing based on location, then proxies are authorized to see location, and, really, I don't know which proxy is doing it. I could use "end to middle" security I suppose, if I knew which element was doing the routing. We could look at that, but I'm reluctant to get into it. Unless you want to propose some new security mechanism just for this header, TLS and S/MIME are all there is, and I would say we should specify TLS if the location is to be used for routing a call, and S/MIME if it is for use only by the endpoint. I think those are SHOULDs, not MUSTs, as long as we can meet the requirements of 3693. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, May 22, 2006 3:56 PM > To: Brian Rosen > Cc: 'Tschofenig, Hannes'; sip@ietf.org; geopriv@ietf.org > Subject: Re: [Geopriv] Explicit Indication of Location Object Consumer > > Hi Brian, > > Brian Rosen wrote: > > I don't see this as a problem. > > > > Let's take the non-emergency case. > > > > If I call take-out@pizza-hut.com, and I want location based routing, I > put > > my location header in the call, and send the call with TLS. My outbound > > proxy will properly ignore it. > > Why do you expect the outbound proxy to ignore it? > > The pizza-hut domain is the one that wants > > to do location based routing, it will get the location and send it off. > I > > don't need to tell it to do that. I could imagine a generic location > based > > routing proxy, but I would not think we would want to mark the location > > header as the way to get it invoked; we need something else (directly, > or > > indirectly, a Route header) to do that. > > > > If I want the endpoint to get it, then I protect it with S/MIME and no > proxy > > sees it. > > I can buy the remark by James that you would put the location object > into the body to tell the proxy not to look at it. > > S/MIME is nice; but maybe it is not always available. > > Ciao > Hannes > > > > > Brian > > > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Monday, May 22, 2006 10:54 AM > > To: Brian Rosen; Hannes Tschofenig; sip@ietf.org; geopriv@ietf.org > > Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > Hi Brian, > > > > > >>I would say no. If the location is not needed by proxies, > >>then I would say > >>you MUST protect it (S/MIME), or it will not be private. > > > > I am less concerned about the security aspects here and more focused the > > protocol operation first. > > Typically, it is good to know for a device whether it has to process the > > content of the message or not. > > > > If you want to prevent intermediaries to inspect your location object > > then S/MIME might be a choice (at least on paper). > > > > > >>If you have to route on it (emergency or otherwise), then you > >>have to send > >>it with TLS, and the proxies can see it. > >> > >>Brian > > > > > > Ciao > > Hannes > > > > > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Sunday, May 21, 2006 7:40 AM > >>To: sip@ietf.org; geopriv@ietf.org > >>Subject: [Geopriv] Explicit Indication of Location Object Consumer > >> > >>Hi James > >>Hi Brian, > >> > >>do you plan to put additional info into the SIP message to > >>indicate who > >>should consume the Location Object (explicity rather than > >>implicit info)? > >> > >>Here is an example: Assume that SIP UA Alice wants to give > >>Bob location > >>information (via reference). Now, Alice could easily indicate that it > >>wants Bob to resolve the reference and to process the > >>location object. > >>Stating this explicitly would prevent proxies to resolve it and to > >>process the location object. > >> > >>Ciao > >>Hannes > >> > >> > >>_______________________________________________ > >>Geopriv mailing list > >>Geopriv@ietf.org > >>https://www1.ietf.org/mailman/listinfo/geopriv > >> > >> > >>_______________________________________________ > >>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 May 22 18:25:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIo1-00051U-Fr; Mon, 22 May 2006 18:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiInz-00051P-Na for sip@ietf.org; Mon, 22 May 2006 18:23:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIny-0001OZ-Cq for sip@ietf.org; Mon, 22 May 2006 18:23:15 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4MMOLxC012942 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 22 May 2006 17:24:26 -0500 In-Reply-To: <4472079B.6090603@lucent.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <446BB2A1.8080700@cisco.com> <17516.4820.496022.112591@rautu.tutpro.com> <446D3D6A.6060604@cisco.com> <4471BCE7.40807@cisco.com> <48BE3E1E-E973-4A44-A755-844C513AAB94@softarmor.com> <4472079B.6090603@lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1767A5F1-1937-405F-BE02-C0A3AA9DE513@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 17:23:06 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.750) 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 On May 22, 2006, at 1:48 PM, Vijay K. Gurbani wrote: > > > This is interesting; so you are in favor of keeping the last > hop behavior as specified in Section 26.2.2 of rfc3261? I believe so. If I recall correctly, that section was left in at my insistence during the final editing of RFC 3261. > But I > don't see the problem if on a P-CSCF -> UA link the security > property is downgraded to sip; the link is protected through > IPSec anyway. Degrading the security property from sips to sip > on the UA -> P-CSCF link seems more of a concern, though. > But, as a caller, how do you KNOW it was protected by IPSEC? You at least have assurances (however meaningless) from RFC 3261 that it was TLS as far as the "proxy responsible for the AOR". You don't even have those vague (and probably meaningless) assertions from RFC 3261 on the P-CSCF to UA link. Yes, you have other assertions "It's SUPPOSED to be IPSEC) from the IMS spec set, but we know nobody ever actually implements that stuff anyhow, right? I maintain that until you have end to end knowledge of the protection, proven by a cert believed to you to be held by the far- end UA (or something equivalent), all you have is a warm feeling and not a believable indication of security -- 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 May 22 18:48:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJAM-0003WU-NI; Mon, 22 May 2006 18:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJAK-0003TY-KJ for sip@ietf.org; Mon, 22 May 2006 18:46:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJAI-0003Cb-5T for sip@ietf.org; Mon, 22 May 2006 18:46:20 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 15:46:17 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="280952949:sNHT33112656" 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/8.12.11) with ESMTP id k4MMkHGl015108; Mon, 22 May 2006 15:46:17 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4MMkHsF002556; Mon, 22 May 2006 15:46:17 -0700 (PDT) Received: from [192.168.1.2] ([10.21.81.9]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 15:46:17 -0700 In-Reply-To: References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C7CAACA-4217-4B5B-9078-B07BBD6F6123@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Mon, 22 May 2006 15:46:14 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 May 2006 22:46:17.0098 (UTC) FILETIME=[895076A0:01C67DF1] DKIM-Signature: a=rsa-sha1; q=dns; l=3770; t=1148337977; x=1149201977; c=relaxed/simple; s=sjdkim5001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3DwUQdvhawa4bCU3L5RVZDcy/QkEc=3D; b=CIMOhtjzH09Jpxg5IMH/mgKiMG2pjGpkEgduGk18i4gO5yneixSrN9W6mc8avpLkiTYz1k9Q af3YhzDznBV3c0KfCpiS7Hpw+E1pXAWv9gt4viW2nxR7nR52kw4P1L8R; 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: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 I'm glad to do that if the intent was relatively clear - if no one can remember what it was, then I would like to ask the WG what it should have been. I have not really tried to track down the history of this and find out if the intent was clear. If you want me to do that first, or have pointers to that, I will do that. On May 22, 2006, at 3:26 PM, Dean Willis wrote: > > Normally all it takes is a note from the AD saying "The IESG's > intent was as specified by the second paragraph, standards-track > RFC required". > > But we'll be happy to drive to WG Consensus if you want. Shall we > document this in the form of an internet-draft? > > -- > Dean > > > On May 22, 2006, at 2:17 PM, Cullen Jennings wrote: > >> >> This is clearly a bug in the spec. Would it be possible for the >> chairs to drive this to WG consensus before or during next >> meeting, get someone to file an errata, and then I will ask for >> IESG to review and get IANA updated to match the errata. Sounds >> like a reasonable plan? >> >> Cullen >> >> >> On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote: >> >>> I'd suggest that it probably should be standards track. URI >>> parameters are a bigger deal than headers, I think, since they >>> are really making changes to the fundamental SIP addressing >>> architecture. I don't think that is something we want everyone >>> doing. >>> >>> -Jonathan R. >>> >>> Cullen Jennings wrote: >>> >>>> On May 9, 2006, at 8:54 PM, Dean Willis wrote: >>>>> >>>>> RFC 3969 defines the registry for SIP/SIPS URI parameters. >>>>> >>>>> It currently says: >>>>> >>>>> 4.2. Registration Policy for SIP and SIPS URI Parameters >>>>> >>>>> As per the terminology in RFC 2434 [4], the registration >>>>> policy for >>>>> SIP and SIPS URI parameters shall be "Specification Required". >>>>> >>>>> For the purposes of this registry, the parameter for which IANA >>>>> registration is requested MUST be defined by a standards- >>>>> track RFC. >>>>> >>>>> >>>>> Note that the above two paragraphs seem to be self >>>>> contradictory. "Specification Required" means 3GPP and >>>>> recognized bodies can define parameters by publishing >>>>> specifications. But"Standards Track RFC" means only IETF can >>>>> do so, and it has to be done with an IETF- consensus standards- >>>>> track document. >>>>> >>>>> Note that the IANA registry currently says: >>>>> >>>>> >>>>> SIP/SIPS URI Parameters RFC3969 Specification Required >>>>> >>>>> SIP/SIPS URI Parameters - per [RFC3969] >>>>> (New registrations are via Specification Required) >>>>> >>>>> This means that the current IANA policy for this registry is >>>>> "Specification Required". >>>>> >>>>> >>>>> Which did we mean? >>>> We might want to check with Allison on history of this but my >>>> vague recollection was last time we discussed this, we decided >>>> we meant "Standards Track". I forget the details and may be >>>> totally wrong. >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP 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 May 22 19:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJYH-0000Ps-6n; Mon, 22 May 2006 19:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJYG-0000Lx-6u for sip@ietf.org; Mon, 22 May 2006 19:11:04 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJYE-0003wE-TJ for sip@ietf.org; Mon, 22 May 2006 19:11:04 -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 k4MN5uQ10781; Mon, 22 May 2006 19:05:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 18:10:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09CDA4C9@zrc2hxm0.corp.nortel.com> In-Reply-To: <1767A5F1-1937-405F-BE02-C0A3AA9DE513@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ97r370Udx5mLNSXqlXq0Jsw6PMAABhlzA From: "Francois Audet" To: "Dean Willis" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 That's section is actually not too bad. It specifically explains what it means for the "last hop to be secure". It's the other places in the document that are less obvious. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, May 22, 2006 15:23 > To: Vijay K. Gurbani > Cc: IETF SIP List > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 >=20 > On May 22, 2006, at 1:48 PM, Vijay K. Gurbani wrote: > > > > > > This is interesting; so you are in favor of keeping the last hop=20 > > behavior as specified in Section 26.2.2 of rfc3261? >=20 > I believe so. If I recall correctly, that section was left in at my =20 > insistence during the final editing of RFC 3261. >=20 >=20 > > But I > > don't see the problem if on a P-CSCF -> UA link the=20 > security property=20 > > is downgraded to sip; the link is protected through IPSec anyway. =20 > > Degrading the security property from sips to sip on the UA=20 > -> P-CSCF=20 > > link seems more of a concern, though. > > >=20 > But, as a caller, how do you KNOW it was protected by IPSEC? You at =20 > least have assurances (however meaningless) from RFC 3261=20 > that it was =20 > TLS as far as the "proxy responsible for the AOR". You don't even =20 > have those vague (and probably meaningless) assertions from RFC 3261 =20 > on the P-CSCF to UA link. Yes, you have other assertions "It's =20 > SUPPOSED to be IPSEC) from the IMS spec set, but we know nobody ever =20 > actually implements that stuff anyhow, right? >=20 > I maintain that until you have end to end knowledge of the =20 > protection, proven by a cert believed to you to be held by the far-=20 > end UA (or something equivalent), all you have is a warm feeling and =20 > not a believable indication of security >=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=20 > 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 sip-implementors@cs.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 May 22 19:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJZm-0001W4-7z; Mon, 22 May 2006 19:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiJZl-0001VW-Gt for sip@ietf.org; Mon, 22 May 2006 19:12:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJZk-00042T-4H for sip@ietf.org; Mon, 22 May 2006 19:12:37 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 16:12:35 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="1810811571:sNHT85685660" 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/8.12.11) with ESMTP id k4MNCZ1G025927; Mon, 22 May 2006 16:12:35 -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 k4MNCZJj005527; Mon, 22 May 2006 16:12:35 -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.211); Mon, 22 May 2006 19:12:34 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 19:12:34 -0400 Message-ID: <44724562.6090508@cisco.com> Date: Mon, 22 May 2006 19:12:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <447215CD.1030801@cisco.com> In-Reply-To: <447215CD.1030801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2006 23:12:34.0726 (UTC) FILETIME=[35A76460:01C67DF5] DKIM-Signature: a=rsa-sha1; q=dns; l=1925; t=1148339555; x=1149203555; c=relaxed/simple; s=sjdkim5001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D1Tq4UWImuOUpLJBCsAbO7xplgqw=3D; b=xVMm1z3gyUPKK5udwE54w3A2Z4kQoWhuq3MR65op8TH2fAPcyUsfxbt6ksSQOs+lm4OhOyc2 dFpuws1Z0R+IkrZoTAhwqkdKTojqu8n96Vc9fVskZTjTO5exn8wBCxcm; 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: c1c65599517f9ac32519d043c37c5336 Cc: Sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Michael Thomas wrote: > Paul Kyzivat wrote: > >> In general nobody seems to know how to deploy a practical system that >> uses S/MIME as the mechanism for this. Some people (myself included) >> had been thinking (falsely it apparently turns out) that SIPS was at >> least part of the mechanism for providing that lock icon. (Also need >> media security, perhaps using sdescriptions over the secure signaling >> path.) > > I'm afraid that this is "elephants all the way down". It's been a while > since > I looked but AFAIK sdescriptions doesn't scale any better to clients, > the basic problem > being interdomain credentials which scale to users in _any_ form. As I understand it, once you have signaling secure enough to suit you, sdescriptions allows you to establish a media session that is more or less of equal security. I don't see why it has any scaling issues. hop by hop security via providers, plus sdescriptions, would seem to give reasonable security from anybody who hasn't penetrated the provider transitive trust network. While I'd like to be secure from the guys (in white hats?) who get to decide which laws apply to them and tell the providers to give them everything, I'll settle for being protected from the rest of the bad guys, for now. Its better than all VoIP going out over the internet in the clear. >> I think we need *some* mechanism that can provide the lock icon in >> plausible deployments. > > Why? Seriously. Maybe the fallacy is that we're striving for a binary > value when reality wants it to be a scale. Or even that we show people > at all. You mean like a lock icon in colors from red to green or something? How would you know how red or green to make it? I think that would just confuse people. If we are not going to provide any indication of privacy, then why bother with things like TLS at all? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 19:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiK7Q-0002NG-7q; Mon, 22 May 2006 19:47:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiK7O-0002N8-My for sip@ietf.org; Mon, 22 May 2006 19:47:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiJ63-0002zk-6u for sip@ietf.org; Mon, 22 May 2006 18:41:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiIrH-0007uR-V5 for sip@ietf.org; Mon, 22 May 2006 18:26:45 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4MMRmtd012990 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 22 May 2006 17:27:50 -0500 In-Reply-To: <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Mon, 22 May 2006 17:26:33 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.1 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Normally all it takes is a note from the AD saying "The IESG's intent was as specified by the second paragraph, standards-track RFC required". But we'll be happy to drive to WG Consensus if you want. Shall we document this in the form of an internet-draft? -- Dean On May 22, 2006, at 2:17 PM, Cullen Jennings wrote: > > This is clearly a bug in the spec. Would it be possible for the > chairs to drive this to WG consensus before or during next meeting, > get someone to file an errata, and then I will ask for IESG to > review and get IANA updated to match the errata. Sounds like a > reasonable plan? > > Cullen > > > On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote: > >> I'd suggest that it probably should be standards track. URI >> parameters are a bigger deal than headers, I think, since they are >> really making changes to the fundamental SIP addressing >> architecture. I don't think that is something we want everyone doing. >> >> -Jonathan R. >> >> Cullen Jennings wrote: >> >>> On May 9, 2006, at 8:54 PM, Dean Willis wrote: >>>> >>>> RFC 3969 defines the registry for SIP/SIPS URI parameters. >>>> >>>> It currently says: >>>> >>>> 4.2. Registration Policy for SIP and SIPS URI Parameters >>>> >>>> As per the terminology in RFC 2434 [4], the registration >>>> policy for >>>> SIP and SIPS URI parameters shall be "Specification Required". >>>> >>>> For the purposes of this registry, the parameter for which IANA >>>> registration is requested MUST be defined by a standards- >>>> track RFC. >>>> >>>> >>>> Note that the above two paragraphs seem to be self >>>> contradictory. "Specification Required" means 3GPP and >>>> recognized bodies can define parameters by publishing >>>> specifications. But"Standards Track RFC" means only IETF can do >>>> so, and it has to be done with an IETF- consensus standards- >>>> track document. >>>> >>>> Note that the IANA registry currently says: >>>> >>>> >>>> SIP/SIPS URI Parameters RFC3969 Specification Required >>>> >>>> SIP/SIPS URI Parameters - per [RFC3969] >>>> (New registrations are via Specification Required) >>>> >>>> This means that the current IANA policy for this registry is >>>> "Specification Required". >>>> >>>> >>>> Which did we mean? >>> We might want to check with Allison on history of this but my >>> vague recollection was last time we discussed this, we decided >>> we meant "Standards Track". I forget the details and may be >>> totally wrong. >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP 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 May 22 21:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLZF-00089Q-Oi; Mon, 22 May 2006 21:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLZE-00089G-Qx for sip@ietf.org; Mon, 22 May 2006 21:20:12 -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 1FiLZE-0000eo-OK for sip@ietf.org; Mon, 22 May 2006 21:20:12 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiLR0-0000tb-0y for sip@ietf.org; Mon, 22 May 2006 21:11:44 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 18:11:41 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="281029747:sNHT27038280" 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/8.12.11) with ESMTP id k4N1BfoD003775; Mon, 22 May 2006 18:11:41 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4N1BesF017762; Mon, 22 May 2006 18:11:40 -0700 (PDT) Received: from [192.168.1.2] ([10.21.81.9]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 18:11:40 -0700 In-Reply-To: <15C5157D-1A28-48CD-8FDB-384E924D5FBE@softarmor.com> References: <446A71D4.4090409@cisco.com> <15C5157D-1A28-48CD-8FDB-384E924D5FBE@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Mon, 22 May 2006 18:11:39 -0700 To: IETF SIP List X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 May 2006 01:11:40.0799 (UTC) FILETIME=[D90B98F0:01C67E05] DKIM-Signature: a=rsa-sha1; q=dns; l=3188; t=1148346701; x=1149210701; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Sip]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3DCg18KnPnK9XQKwOiXfehRLUYf3k=3D; b=zs/jyhFq8KXbaM3Y5ZN88liQwuHIsX3jcDQjOTR5eA5F66/s4fuVKlzi1aw6quJR7OovqVFC 1k0iDN/FhvrrwL++hjleCmQq18b6LCpTZbF+G91aXI1D8QzlTv231hPR; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.4 (--) 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 think that we all agree that with sips you never know that know if one of the proxies cheated and that you do not have e2e security. Sure e2e would be better but that's not what sips gives you. I imagine that we might all be convinced that IP over Brinks was equivalently secure to TLS. The questions is, can we figure out how to specify SIP well enough that we allow IP over Brinks and don't end up having implementers implement something far weaker than TLS on every hop. My point is, I don't think this is a questions about absolute level of theoretical security that we can achieve, I think it is a question about how good we are at writing specifications for abstract security protocols (such as IP over Brinks). Given that our previous attempt at specifying sips clearly had some, ah, small holes in it, I initial gut feeling is to write something very narrow, simple, and easy to specify. Then as needs arise for sips to be transported over something other than TLS, carefully extend the previous RFC to cover the new secure transports. This could be all wrong, perhaps we can get the more abstract version tightly specified. Cullen On May 17, 2006, at 3:28 PM, Dean Willis wrote: > > On May 16, 2006, at 7:44 PM, Jonathan Rosenberg wrote: > >> >> I'd propose that, to be useful, sips has to do as it implies - it >> means that each and every link from UAC to UAS was secure. This >> means two things: >> >> 1. SIPS requires the usage of TLS at every hop - none of this >> weasel words on IPSec >> >> 2. there is no upgrading or downgrading, period >> > > So, how do you KNOW that TLS was actually used at each hop? > > Until you have a way to KNOW that it was, all you have is a vague > hope that the serving proxy to UA link was secured properly, and no > amount of "MUST" in the specification is going to change it. You'll > have added feel-good words to the specification that don't actually > improve the security characteristics. > > Not only that, but you will have prevented "real deployable > security" where some links -- like UA to serving proxy -- are > actually secured by something like IMS-IPSEC. Net result, everybody > will just use sip:, and the security situation will actually > degrade relative to where it is today (where sips: works at least > part of the time). > > TLS works with HTTP because it works end-to-end, tunneling through > the HTTP proxies. If a proxy cheats and acts like a B2BUA for TLS, > the client can check the cert-name and detect the misbehavior. But > with sips:, we have no way for the UAC to "check up" on the proxies. > > For sips: to give the kind of security assurance you seem to want, > it has to work end-to-end "through" the proxies, like https: does. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 22 21:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiM7F-0004Zo-OH; Mon, 22 May 2006 21:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiM7D-0004Zi-Pq for sip@ietf.org; Mon, 22 May 2006 21:55:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiM7A-0002VD-EI for sip@ietf.org; Mon, 22 May 2006 21:55:19 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 22 May 2006 18:53:36 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="281044415:sNHT7420954988" 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/8.12.11) with ESMTP id k4N1raer030461; Mon, 22 May 2006 18:53:36 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4N1rasF027738; Mon, 22 May 2006 18:53:36 -0700 (PDT) Received: from [192.168.1.2] ([10.21.81.9]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 18:53:36 -0700 In-Reply-To: <1148312948.13541.9.camel@niagra.pingtel.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 18:53:35 -0700 To: "Dale R. Worley" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 May 2006 01:53:36.0190 (UTC) FILETIME=[B455CDE0:01C67E0B] DKIM-Signature: a=rsa-sha1; q=dns; l=1672; t=1148349216; x=1149213216; c=relaxed/simple; s=sjdkim7001; 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-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DE54Y2jKJfJW44o2SgsDknJKV26I=3D; b=FhBbwTkvgdOC3XurkTzyoVx7LLWcNzLKpU6TI31bXjCtuXi4qBBlmMQ1P26JI8/b8DPhkyMj I1Tf4MAbEoBShxC7Hd9q3t1wuvy37GPZa0faRBSlYCZ92YNlhrUZq2ZN; 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: cab78e1e39c4b328567edb48482b6a69 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Identity? On May 22, 2006, at 8:49 AM, Dale R. Worley wrote: > I admit I'm late to this discussion, but it seems to me that there > is a > reasonable purpose to which sips can be put: > > Provide assurance of a reasonable level of security between the caller > and the callee, unless one of the servers under control of either the > caller or the callee (or their agents, or organizations delegating > their > domain names or certifying their certificates) has been subverted. > > Specifically, it protects against passive packet sniffing to, let us > say, the 40-bit key level. > > This seems to me to a minimal definition of a practically useful level > of security of this sort, and I can envision it being implemented, > though I can't enumerate all the details, and I can see the mechanism > activated by using a sips: request-URI. > > But I can't see how security could be established in the reverse > direction, how the callee could have assurance that the call > originated > from the From: URI. And without that, I can't see how we could > describe > what the sips mechanism guarantees in a way that is strong enough > to be > practically useful, as the callee wouldn't know the set of server that > it is trusting. > > But perhaps someone else has a solution to that problem. > > 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 May 22 21:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiM83-0004bj-P6; Mon, 22 May 2006 21:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiM82-0004bZ-7K for sip@ietf.org; Mon, 22 May 2006 21:56:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiM7y-0002Yw-T0 for sip@ietf.org; Mon, 22 May 2006 21:56:10 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 18:53:32 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="1810895368:sNHT12415078540" 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/8.12.11) with ESMTP id k4N1rV6N030439; Mon, 22 May 2006 18:53:31 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4N1rVJj022347; Mon, 22 May 2006 18:53:31 -0700 (PDT) Received: from [192.168.1.2] ([10.21.81.9]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 18:53:31 -0700 In-Reply-To: <44721139.9020701@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 22 May 2006 18:53:29 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 May 2006 01:53:31.0268 (UTC) FILETIME=[B166C440:01C67E0B] DKIM-Signature: a=rsa-sha1; q=dns; l=1072; t=1148349211; x=1149213211; c=relaxed/simple; s=sjdkim7001; 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-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DE54Y2jKJfJW44o2SgsDknJKV26I=3D; b=WYs40ljyFsgXWOzb1Jwe9xX/7VpBJsTWKSk51nXkF7R8xeJUPsBMYFromuWYMZmU2S4+sl/N VvTB0TL31baGHf1qCRKbOpzsvLtkGCcz4h8aadpNF4n18QLcjytE40AU; 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: 93238566e09e6e262849b4f805833007 Cc: Sip , Michael Thomas , 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 May 22, 2006, at 12:30 PM, Paul Kyzivat wrote: > I suspect that the lock icon will be driven by policy in the UAs, > and that in many cases will be coupled to the service provider > policies. > > In general nobody seems to know how to deploy a practical system > that uses S/MIME as the mechanism for this. Some people (myself > included) had been thinking (falsely it apparently turns out) that > SIPS was at least part of the mechanism for providing that lock > icon. (Also need media security, perhaps using sdescriptions over > the secure signaling path.) > > I think we need *some* mechanism that can provide the lock icon in > plausible deployments. I think that is one of the topics this whole rtpsec list needs to figure out - what are *all* the parts one needs to get to this and what would it mean. Clearly sips by itself will not provide this - actually it is not clear that sips helps at all this this though it is useful for a bunch of other things like trying to make sure your INVITE is not misrouted. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 22 22:25:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMXM-0000Jt-MA; Mon, 22 May 2006 22:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiMXL-0000Jo-7K for sip@ietf.org; Mon, 22 May 2006 22:22:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiMXJ-0003bf-Ul for sip@ietf.org; Mon, 22 May 2006 22:22:19 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 19:22:16 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="1810905808:sNHT4970111704" 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/8.12.11) with ESMTP id k4N2MFG6006392; Mon, 22 May 2006 19:22:15 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4N2MDJj000412; Mon, 22 May 2006 19:22:13 -0700 (PDT) Received: from [192.168.1.2] ([10.21.81.9]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 19:22:13 -0700 In-Reply-To: <31529C1D0F94F24989CBC1BCDF3C04970818BE54@S4DE8PSAAGT.blf.telekom.de> References: <31529C1D0F94F24989CBC1BCDF3C04970818BE54@S4DE8PSAAGT.blf.telekom.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E356D4B-E5B7-43AE-B7EA-7E95F0D191AC@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Mon, 22 May 2006 19:22:11 -0700 To: "Jesske, R" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 May 2006 02:22:13.0478 (UTC) FILETIME=[B3EB2860:01C67E0F] DKIM-Signature: a=rsa-sha1; q=dns; l=989; t=1148350935; x=1149214935; c=relaxed/simple; s=sjdkim7001; 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=20AW=3A=20[Sip]=20Issue=201=20in=20draft-ietf-sip-connected-identi ty-00.txt; X=v=3Dcisco.com=3B=20h=3DrGqJkrv3ac7y9bluvpZqhcIOTpc=3D; b=RUqkmXl5Fxn+7c/qZxYAMtiKlORvYe+olaAk+cSyRnoAssku8HyP2IC6yY3XZcyzahejeZE6 x+ZYiiOyKAoAu7GLIvTs5aY5I1d2ciMyPPqH0afj8wGnmMdRniWwfrLW; 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: 79899194edc4f33a41f49410777972f8 Cc: chister.holmberg@ericsson.com, sip@ietf.org, christer.holmberg@ericsson.com, esasaki@NTT-AT.COM, john.elwell@siemens.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 May 8, 2006, at 3:52 AM, Jesske, R wrote: > The discussion showed it that there is no harm in changing the to > header field in a response. I think there has been several emails that point out the implications of this do cause harm (check out pretty much any post on the subject from Jon Peterson). This has been a very long running debate and was discussed for several years with agenda time at many meetings. The change the To and put Identity in response solution has been considered and I think people have tried to explain the issues with it - I'm glad to spend some more time explaining that. However, much more productive would be trying to move off of this solution a little and look at the requirements. What do we need to do - I think there are some straw- man proposal that meet many of the requirements and do work. Understanding what requirements they have issues would would be good and help make them so they could be used. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 23 02:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiQnA-0004Zp-4N; Tue, 23 May 2006 02:54:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiQn8-0004Zk-98 for sip@ietf.org; Tue, 23 May 2006 02:54:54 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiQn6-0007Hb-Tw for sip@ietf.org; Tue, 23 May 2006 02:54:54 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 202F41400BB; Tue, 23 May 2006 09:54:47 +0300 (EEST) Received: from rautu (mitosis109.gprs.dnafinland.fi [62.78.122.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 2818B1400A3; Tue, 23 May 2006 09:54:37 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id DA8F2F01D5; Tue, 23 May 2006 09:54:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17522.45483.589133.702489@rautu.tutpro.com> Date: Tue, 23 May 2006 09:54:35 +0300 From: Juha Heinanen To: Cullen Jennings Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Sip , Paul Kyzivat , Michael Thomas , 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 this discussion has clearly revealed that meaning of sips uri scheme is not well defined in rfc3261 and that there exist wide confusion and conflicting opinions about it. as i mentioned earlier, sips was added to rfc3261 at the very last minute, which clearly was a mistake. sip working group must have guts to admit it and act accordingly. since there is no indication that an easy fix could exist, i therefore propose deprecating sips uri scheme until it is well defined and can be reintroduced. this would be a big benefit to sip implementors. -- 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 May 23 03:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRe4-0006Q2-MG; Tue, 23 May 2006 03:49:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRe3-0006Pw-4d for sip@ietf.org; Tue, 23 May 2006 03:49:35 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRe0-0000yR-I9 for sip@ietf.org; Tue, 23 May 2006 03:49:35 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4N7nSxj007046; Tue, 23 May 2006 10:49:29 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 10:49:29 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 10:49:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? Date: Tue, 23 May 2006 10:49:25 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> In-Reply-To: <001801c66e98$98b8a580$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? Thread-Index: AcZumNucfH2ftZ6wT+qSwv2M5rlM2QPmAWog From: To: X-OriginalArrivalTime: 23 May 2006 07:49:29.0033 (UTC) FILETIME=[6B9F1390:01C67E3D] X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi ! I have finally got some time to study the SIP Outbound=20 autodiscovery further based on the comments given to the I-D. The choice betweeen DNS NAPTR and TXT records seems to be a difficult one. The two options proposed are as=20 follows: A. Define new values for NAPTR service field as "SIP-O+D2X",=20 where X will be replaced with a letter indicating transport protocol. Service "SIP-O" means support for SIP Outbound, while "SIPS-O" indicates additional TLS/SIPS URI support. B. Associate DNS TXT records with the SRV records for servers supporting SIP Outbound. Those TXT records would contain a value like "sip-outbound" when server supports SIP Outbound. Further on define a new "t" flag for SRV records to give a hint to the server to return all related TXT record as additional information. The benefits (+) and drawbacks (-) of these solutions seem to=20 be as follows: A. NAPTR records + When responding to one NAPTR query the DNS server typically returns=20 not only the NAPTR records but also the related SRV and address=20 records as the NAPTR and SRV RFCs already suggest doing so. Thus with a single DNS query the UA would get all the needed information. + Using different NAPTR service types for SIP Outbound would make it straightforward for an operator to divide its servers to two farms: Servers with SIP Outbound to be used by clients of the service provider and servers without SIP Outbound to be used by external UAs. As the external UAs would NOT need SIP Outbound, when they resolve the SIP URI of callee in the conventional (RFC 3263) way, the result would be those servers without SIP Outbound support, which is the desired outcome. - Both the UA and DNS server would have to support NAPTR RRs, which is not always the case currently. Some DNS service providers do not allow NAPTR RRs and the UA support is not always there. - The number of NAPTR service types for SIP would double (from current five to ten) and as indicated in RFC 3486, this is not a scalable way of using DNS. If in the future yet another combination would be needed to double the number of NAPTR service types for SIP, then there would be 20 types, which sounds excessive. B. TXT records + There are no combinatorial problems by introducing new flags into TXT records, since any new flag is just another text string to be added amongst the others. + Adding TXT RR support for UAs does not seem a very challenging task, whether or not the UA already supports NAPTR RRs. - There is no built-in way for the service provider to prevent the clients of other service providers to resolve SIP URIs to proxies supporting SIP Outbound (aimed to be used only by the local clients as outbound proxies for NAT traversal). - If the server does not understand or obey the new "t" flag of SRV RR, then the UA has to separately query the TXT records for every SRV record it tries to use. This might lead to N x TXT RR queries before the SIP server has finally been located.=20 - Both the UA and DNS server would have to support TXT RRs, however even those are not allowed by some DNS service providers even if the servers might already support those almost universally. For the pure technical point of view I am currently slightly=20 inclined towards using TXT records, but NAPTR also has its advantages. However I am worried about the fact that TXT records are almost too "general purpose" and I am not aware of any other standarized solutions relying only on TXT records: - SPF uses TXT records only as a fallback solution in case=20 where the DNS server does not yet support SPF records, the same seems to apply to DKIM RRs. However for SIP Outbound, defining new RR types for one single boolean flag is not a feasible solution. - For DNS-SD there is only an expired I-D and there seems to be no movement to get it approved as an RFC. Also this kind of comments would make me doubt if the solution based on TXT records is eventually acceptable (even if the use of TXT records in SIP Outbound case would be straightforward): > A word of caution: use of TXT records will get you an=20 > earful from the IAB. The entire area is a huge tangle=20 > and you need to be extremely cautious about how you use=20 > TXT records. So I would like to get your comments or 'hum' for one option or another. I have already prepared a second version of the I-D with a new way of using SRV records to find the target=20 host for the backup flow, based on the comments received=20 for this subject. Now the final issue before publishing=20 this edition is whether to use NAPTR and TXT records to indicate support for SIP Outbound. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 04:04:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRqU-0002qZ-Df; Tue, 23 May 2006 04:02:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRqS-0002qT-VO for sip@ietf.org; Tue, 23 May 2006 04:02:24 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRqR-0001Tr-Gy for sip@ietf.org; Tue, 23 May 2006 04:02:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4N82KrI028788; Tue, 23 May 2006 11:02:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 11:01:55 +0300 Received: from [172.21.35.183] ([172.21.35.183]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 May 2006 11:01:55 +0300 Message-ID: <4472C172.3060000@nokia.com> Date: Tue, 23 May 2006 11:01:54 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> In-Reply-To: <44720282.8090705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2006 08:01:55.0486 (UTC) FILETIME=[288AC3E0:01C67E3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Michael Thomas wrote: > I'm with you so far, but: > >> So given that sips as opposed to sip is above all else a strong >> indication to the *human* user about security, anything less than e2e is >> not going to cut it. So it doesn't matter how each hop of a hop-by-hop >> path is secured, it's still not lockworthy for me. > > Is it really intended for _direct_ human consumption? I sure hope not. I think directly in a sense that a user might need to make a decision between two addresses in, say, a business card or a phonebook contact: Tel (Internet): sip:foo@example.com Tel (Internet, Secure): sips:foo@example.com >> To make sips really useful (again thinking of the lock icon here), and >> given *real* security for a call requires that the media streams are >> secure, then if anything, sips should mean secure media must be used. >> But then that requires a whole lot more than requiring a specific >> transport between SIP nodes. >> >> > > I don't really think this follows: the decision to put up the "lock" > icon could > and probably should weigh a lot of factors, and it's not always going to > yeild > the same result for all situtations. For example, when starting a > "secure" session > for, oh say, the Kremlin to the Whitehouse, I'm pretty sure that nothing > short > of S/MIME is going to do. Perhaps, but then again SIP identity, and MIKEY'd SRTP might suffice if it was President Halonen from Helsinki calling the Whitehouse. ;) Like Cullen pointed out, this may ultimately be something rtpsec needs to address; in any case I think we agree hop-by-hop TLS alone is not enough to call it sips or lockworthy. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 04:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRrk-0003Le-6X; Tue, 23 May 2006 04:03:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRri-0003Jv-KA for sip@ietf.org; Tue, 23 May 2006 04:03:42 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRrg-0001ay-6s for sip@ietf.org; Tue, 23 May 2006 04:03:42 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 6ABB41400A6; Tue, 23 May 2006 11:03:34 +0300 (EEST) Received: from rautu (telomeres117.gprs.dnafinland.fi [62.78.111.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id CFAED13F97F; Tue, 23 May 2006 11:03:27 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id C4830F01D5; Tue, 23 May 2006 11:03:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17522.49609.688036.884066@rautu.tutpro.com> Date: Tue, 23 May 2006 11:03:21 +0300 From: Juha Heinanen To: Subject: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> References: <001801c66e98$98b8a580$31713b51@BEMBUSTER> <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 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 Erkki.Koivusalo@nokia.com writes: > + When responding to one NAPTR query the DNS server typically returns > not only the NAPTR records but also the related SRV and address > records as the NAPTR and SRV RFCs already suggest doing so. Thus > with a single DNS query the UA would get all the needed > information. this is definitely a valuable feature. > + Using different NAPTR service types for SIP Outbound would make it > straightforward for an operator to divide its servers to two farms: > Servers with SIP Outbound to be used by clients of the service > provider and servers without SIP Outbound to be used by external > UAs. As the external UAs would NOT need SIP Outbound, when they > resolve the SIP URI of callee in the conventional (RFC 3263) way, > the result would be those servers without SIP Outbound support, > which is the desired outcome. this is mandatory feature. if txt records cannot be made to provide separation of servers to these two classes, then they are not an acceptable choice. > - The number of NAPTR service types for SIP would double (from current > five to ten) and as indicated in RFC 3486, this is not a scalable > way of using DNS. in practice, we can get rid of sips-o. -- 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 May 23 05:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiTT9-0004lp-7O; Tue, 23 May 2006 05:46:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiTT7-0004lj-Sk for sip@ietf.org; Tue, 23 May 2006 05:46:25 -0400 Received: from [203.187.132.2] (helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiTSs-0006Ec-5y for sip@ietf.org; Tue, 23 May 2006 05:46:25 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.11.6) with ESMTP id k4N9jtME014545 for ; Tue, 23 May 2006 15:15:55 +0530 To: Sip MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: P Thejeswara Reddy Date: Tue, 23 May 2006 15:15:51 +0530 X-MIMETrack: S/MIME Sign by Notes Client on P Thejeswara Reddy/BLR/HSS(Release 6.5.1|January 21, 2004) at 05/23/2006 03:15:51 PM, Serialize by Notes Client on P Thejeswara Reddy/BLR/HSS(Release 6.5.1|January 21, 2004) at 05/23/2006 03:15:51 PM, Serialize complete at 05/23/2006 03:15:51 PM, S/MIME Sign failed at 05/23/2006 03:15:51 PM: The cryptographic key was not found, Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/23/2006 03:15:29 PM, Serialize complete at 05/23/2006 03:15:29 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Sip] Fw: [Sip-implementors] Miss-ordered re-INVITE request X-BeenThere: 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="===============1824714138==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1824714138== Content-Type: multipart/alternative; boundary="=_alternative 0035A30B65257177_=" This is a multipart message in MIME format. --=_alternative 0035A30B65257177_= Content-Type: text/plain; charset="US-ASCII" Hi, What is the response code in the following scenario. UA-1 UA-2 ------INVITE ---------> <------200 ------------ ------- ACK -----------> ------ re-INVITE-1-----> <------200 ------------ --------Ack lost-- ------ re-INVITE-2-----> <------ Response code?? ---- Thanks Thejeswara Reddy ----- Forwarded by P Thejeswara Reddy/BLR/HSS on 05/23/2006 03:11 PM ----- "Gupta, Ajay" Sent by: sip-implementors-bounces@cs.columbia.edu 05/23/2006 07:32 AM To "Leonid Fainshtein" , cc Subject Re: [Sip-implementors] Miss-ordered re-INVITE request The UA-2 should send a 491 response for the re-INVITE-2 with a Retry-After header. It is true that the 491 response will not result in the ACK generation for re-INVITE-1 but at the same time the UA-2 should also retransmit the 200 response for the re-INVITE-1 which will result in the ACK from UA-1 Ajay -----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Leonid Fainshtein Sent: Saturday, May 20, 2006 3:24 PM To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Miss-ordered re-INVITE request Hi, Is the following UAS behavior correct? UA-1 UA-2 ------INVITE ---------> <------200 ------------ ------- ACK ----------> ------ re-INVITE-1-----> <------200 ------------ ------ re-INVITE-2-----> <------ 400( with Retry-After header) ---- As you can see, the second re-INVITE arrives to the UAS when the previous re-INVITE transaction is not confirmed yet (ACK is not received). What should UAS do in this situation? Silently ignore re-INVITE2? Reject it with response 400 or 500? Thanks, Leonid _______________________________________________ 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 *********************** FSS-Private *********************** --=_alternative 0035A30B65257177_= Content-Type: text/html; charset="US-ASCII"

Hi,
What is the response code in the following scenario.

UA-1                   UA-2
------INVITE --------->
<------200 ------------
------- ACK ----------->
------ re-INVITE-1----->
<------200 ------------
--------Ack lost--
------ re-INVITE-2----->
<------ Response code?? ----




Thanks
Thejeswara Reddy
----- Forwarded by P Thejeswara Reddy/BLR/HSS on 05/23/2006 03:11 PM -----
"Gupta, Ajay" <ajgupta@verisign.com>
Sent by: sip-implementors-bounces@cs.columbia.edu

05/23/2006 07:32 AM

To
"Leonid Fainshtein" <LFAIN@ipgear.net>, <sip-implementors@cs.columbia.edu>
cc
Subject
Re: [Sip-implementors] Miss-ordered re-INVITE request






The UA-2 should send a 491 response for the re-INVITE-2 with a
Retry-After header. It is true that the 491 response will not result in
the ACK generation for re-INVITE-1 but at the same time the UA-2 should
also retransmit the 200 response for the re-INVITE-1 which will result
in the ACK from UA-1

Ajay

-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Leonid
Fainshtein
Sent: Saturday, May 20, 2006 3:24 PM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] Miss-ordered re-INVITE request

Hi,

Is the following UAS behavior correct?

UA-1                   UA-2
------INVITE --------->
<------200 ------------
------- ACK ---------->
------ re-INVITE-1----->
<------200 ------------

------ re-INVITE-2----->
<------ 400( with Retry-After header) ----

As you can see, the second re-INVITE arrives to the UAS when the
previous re-INVITE transaction is not confirmed yet (ACK is not
received).
What should UAS do in this situation? Silently ignore re-INVITE2? Reject
it with response 400 or 500?
Thanks,
Leonid

_______________________________________________
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


***********************  FSS-Private   *********************** --=_alternative 0035A30B65257177_=-- --===============1824714138== 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 --===============1824714138==-- From sip-bounces@ietf.org Tue May 23 06:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUPJ-0001si-LO; Tue, 23 May 2006 06:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUPH-0001rF-CM for sip@ietf.org; Tue, 23 May 2006 06:46:31 -0400 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiUEw-0008VM-9R for sip@ietf.org; Tue, 23 May 2006 06:35:54 -0400 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k4NAYwu8006546; Tue, 23 May 2006 12:34:58 +0200 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k4NAYvsY017407; Tue, 23 May 2006 12:34:57 +0200 Message-ID: <4472E55A.7040903@alcatel.fr> Date: Tue, 23 May 2006 12:35:06 +0200 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: P Thejeswara Reddy Subject: Re: [Sip] Fw: [Sip-implementors] Miss-ordered re-INVITE request References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: "sip@ietf.org 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 the answer is 491 "request pending": see section 14.2 of RFC 3261: "A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending)" Thomas P Thejeswara Reddy wrote: > > > Hi, > What is the response code in the following scenario. > > UA-1 UA-2 > ------INVITE ---------> > <------200 ------------ > ------- ACK -----------> > ------ re-INVITE-1-----> > <------200 ------------ > --------Ack lost-- > ------ re-INVITE-2-----> > <------ Response code?? ---- > > > > > Thanks > Thejeswara Reddy > > > > > ----- Forwarded by P Thejeswara Reddy/BLR/HSS on 05/23/2006 03:11 PM > ----- > *"Gupta, Ajay" * > Sent by: sip-implementors-bounces@cs.columbia.edu > > 05/23/2006 07:32 AM > > > To > "Leonid Fainshtein" , > > cc > > Subject > Re: [Sip-implementors] Miss-ordered re-INVITE request > > > > > > > > > > > The UA-2 should send a 491 response for the re-INVITE-2 with a > Retry-After header. It is true that the 491 response will not result in > the ACK generation for re-INVITE-1 but at the same time the UA-2 should > also retransmit the 200 response for the re-INVITE-1 which will result > in the ACK from UA-1 > > Ajay > > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu > [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Leonid > Fainshtein > Sent: Saturday, May 20, 2006 3:24 PM > To: sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Miss-ordered re-INVITE request > > Hi, > > Is the following UAS behavior correct? > > UA-1 UA-2 > ------INVITE ---------> > <------200 ------------ > ------- ACK ----------> > ------ re-INVITE-1-----> > <------200 ------------ > > ------ re-INVITE-2-----> > <------ 400( with Retry-After header) ---- > > As you can see, the second re-INVITE arrives to the UAS when the > previous re-INVITE transaction is not confirmed yet (ACK is not > received). > What should UAS do in this situation? Silently ignore re-INVITE2? Reject > it with response 400 or 500? > Thanks, > Leonid > > _______________________________________________ > 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 > > > *********************** FSS-Private *********************** > >------------------------------------------------------------------------ > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 23 06:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUPI-0001s7-QQ; Tue, 23 May 2006 06:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUPG-0001rF-HW; Tue, 23 May 2006 06:46:30 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiUFi-000082-EU; Tue, 23 May 2006 06:36:39 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 05:36:53 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 23 May 2006 05:36:52 -0500 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 05:36:52 -0500 Message-ID: From: "Winterbottom, James" To: "Tschofenig, Hannes" , "Brian Rosen" , "Hannes Tschofenig" , , Date: Tue, 23 May 2006 05:36:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 23 May 2006 10:36:52.0531 (UTC) FILETIME=[CE034030:01C67E54] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Geopriv] Explicit Indication of Location Object Consumer Thread-Index: AcZ8y171SM4OF0/kSVCdzR6o3vg4ewAcC75AAAA7NwAAG/KsEAAqBRSw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 don't see an explicit indicator being required. If the proxy needs it for routing, and it can't get access to it, then the call will fail. If the end-point can't get access to it, then the result is application dependent. > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Tuesday, 23 May 2006 12:39 AM > To: Winterbottom, James; Brian Rosen; Hannes Tschofenig; sip@ietf.org; > geopriv@ietf.org > Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer >=20 > Hi James, >=20 > > I am inclined to agree with Brian here. > > > > I am not sure why a proxy would just pickout a location URI and > > de-reference it unless the proxy needed to use it in some way anyway. > > Perhaps the example is not such a good one. Hannes do you > > have something > > more concrete in mind? >=20 > The location conveyance draft has emergency and non-emergency > applications in mind. > With emergency calls you want the proxy and the PSAP (as the other end > of the call) to process the location objects. > For non-emergency applications you either might want the proxy (for > location-based routing or the end host to process the LO; or even both). > So, do you think there is no need to tell which entity should process > it? >=20 > Ciao > Hannes >=20 > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, 22 May 2006 11:05 AM > > > To: 'Hannes Tschofenig'; sip@ietf.org; geopriv@ietf.org > > > Subject: RE: [Geopriv] Explicit Indication of Location > > Object Consumer > > > > > > I would say no. If the location is not needed by proxies, then I > > would > > > say > > > you MUST protect it (S/MIME), or it will not be private. > > > > > > If you have to route on it (emergency or otherwise), then > > you have to > > send > > > it with TLS, and the proxies can see it. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Sunday, May 21, 2006 7:40 AM > > > To: sip@ietf.org; geopriv@ietf.org > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > Hi James > > > Hi Brian, > > > > > > do you plan to put additional info into the SIP message to indicate > > who > > > should consume the Location Object (explicity rather than implicit > > info)? > > > > > > Here is an example: Assume that SIP UA Alice wants to give Bob > > location > > > information (via reference). Now, Alice could easily > > indicate that it > > > wants Bob to resolve the reference and to process the > > location object. > > > Stating this explicitly would prevent proxies to resolve it and to > > > process the location object. > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 07:31:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiV4c-0000tK-4h; Tue, 23 May 2006 07:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiV4a-0000tF-VK for sip@ietf.org; Tue, 23 May 2006 07:29:12 -0400 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiV4Y-0002V7-Ch for sip@ietf.org; Tue, 23 May 2006 07:29:12 -0400 Received: from missrv1.nextenso.alcatel.fr (proxy.nextenso.alcatel.fr [139.54.130.250]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k4NBSibT023057; Tue, 23 May 2006 13:28:44 +0200 Received: from [139.54.131.75] (nx1075.nextenso.alcatel.fr [139.54.131.75]) by missrv1.nextenso.alcatel.fr (8.12.8/8.12.8) with ESMTP id k4NBSgsY017605; Tue, 23 May 2006 13:28:42 +0200 Message-ID: <4472F1F3.1040404@alcatel.fr> Date: Tue, 23 May 2006 13:28:51 +0200 From: Thomas Froment Organization: Alcatel User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) X-Accept-Language: en-us, en MIME-Version: 1.0 To: P Thejeswara Reddy Subject: Re: [Sip] Fw: [Sip-implementors] Miss-ordered re-INVITE request References: <4472E55A.7040903@alcatel.fr> In-Reply-To: <4472E55A.7040903@alcatel.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: "sip@ietf.org 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 sorry, I realized this is probably not the right answer... This case is actually not described, 491 is for the case where UAS has sent an INVITE on its side... I found the following thread in archives: http://www1.ietf.org/mail-archive/web/sip/current/msg12768.html In Section 14.2 UAS Behavior of RFC 3261, it says: If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog. That is, the UAS SHOULD terminate the dialog. But because the misorder of the SIP messages, sometimes the UAS SHOULD NOT terminate the dialog as I considered. The UAS can have several choices to handle in this case: 1. Terminate the dialog as the specification. This is not reasonable in some cases and it is not a good idea. 2. UAS can accept the re-INVITE and wait for ACK. It can handle the re-INVITE before the ACK comes or after ACK comes. If before ACK, the case will becomes more complicated if maybe the ACK will take SDP answer back. But if after ACK comes, it must buffer it. This is not a good idea, I think. 3. UAS can ignore the re-INVITE because UAC will re-transmit again. UAS can accept it after ACK comes simply. 4. As Section 14.2 of RFC3261: A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE. UAS can reject the re-INVITE temporarily by 491 and UAC side will initiate another try several seconds later. Thomas.Froment@alcatel.fr wrote: > I think the answer is 491 "request pending": > see section 14.2 of RFC 3261: > "A UAS that receives an INVITE on a dialog while an INVITE it had > sent on that dialog is in progress MUST return a 491 (Request Pending)" > > Thomas > > P Thejeswara Reddy wrote: > >> >> >> Hi, >> What is the response code in the following scenario. >> >> UA-1 UA-2 >> ------INVITE ---------> >> <------200 ------------ >> ------- ACK -----------> >> ------ re-INVITE-1-----> >> <------200 ------------ >> --------Ack lost-- >> ------ re-INVITE-2-----> >> <------ Response code?? ---- >> >> >> >> >> Thanks >> Thejeswara Reddy >> >> >> >> >> ----- Forwarded by P Thejeswara Reddy/BLR/HSS on 05/23/2006 03:11 PM >> ----- >> *"Gupta, Ajay" * >> Sent by: sip-implementors-bounces@cs.columbia.edu >> >> 05/23/2006 07:32 AM >> >> >> To >> "Leonid Fainshtein" , >> >> cc >> >> Subject >> Re: [Sip-implementors] Miss-ordered re-INVITE request >> >> >> >> >> >> >> >> >> >> >> The UA-2 should send a 491 response for the re-INVITE-2 with a >> Retry-After header. It is true that the 491 response will not result in >> the ACK generation for re-INVITE-1 but at the same time the UA-2 should >> also retransmit the 200 response for the re-INVITE-1 which will result >> in the ACK from UA-1 >> >> Ajay >> >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu >> [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Leonid >> Fainshtein >> Sent: Saturday, May 20, 2006 3:24 PM >> To: sip-implementors@cs.columbia.edu >> Subject: [Sip-implementors] Miss-ordered re-INVITE request >> >> Hi, >> >> Is the following UAS behavior correct? >> >> UA-1 UA-2 >> ------INVITE ---------> >> <------200 ------------ >> ------- ACK ----------> >> ------ re-INVITE-1-----> >> <------200 ------------ >> >> ------ re-INVITE-2-----> >> <------ 400( with Retry-After header) ---- >> >> As you can see, the second re-INVITE arrives to the UAS when the >> previous re-INVITE transaction is not confirmed yet (ACK is not >> received). >> What should UAS do in this situation? Silently ignore re-INVITE2? Reject >> it with response 400 or 500? >> Thanks, >> Leonid >> >> _______________________________________________ >> 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 >> >> >> *********************** FSS-Private *********************** >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 23 10:12:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXZ6-0008PM-6l; Tue, 23 May 2006 10:08:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXZ4-0008PA-CO; Tue, 23 May 2006 10:08:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXZ1-0000rj-Oe; Tue, 23 May 2006 10:08:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 23 May 2006 07:08:45 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="281340843:sNHT5443088796" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4NE8i0v021287; Tue, 23 May 2006 07:08:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4NE8fHc005703; Tue, 23 May 2006 07:08:41 -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.211); Tue, 23 May 2006 07:08:41 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.14]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 07:08:41 -0700 Message-Id: <4.3.2.7.2.20060523090449.018d75a0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 May 2006 09:08:40 -0500 To: "Winterbottom, James" , "Tschofenig, Hannes" , "Brian Rosen" , "Hannes Tschofenig" , , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 23 May 2006 14:08:41.0239 (UTC) FILETIME=[64FE3270:01C67E72] DKIM-Signature: a=rsa-sha1; q=dns; l=5161; t=1148393324; x=1149257324; c=relaxed/simple; s=sjdkim3001; 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]=20Explicit=20Indication=20of=20Location=20Object=20Con sumer; X=v=3Dcisco.com=3B=20h=3DIvJNWI/vaUJzVdAJMjWlCgWB9Vs=3D; b=Pl41Q9cYuavYOeb/fmFzEQA7awWK6x7d8W47G4mj5j7P1O12ySo3o6UlmRKOx8D+jT2n0mw2 NaHhrrG6lwtudmjxNKu8SX5qpj10oymlGRMIvxWsie1CMF+ZgdCs/8zN; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Subject: [Sip] RE: [Geopriv] Explicit Indication of Location Object Consumer X-BeenThere: sip@ietf.org X-Mailman-Version: 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 05:36 AM 5/23/2006 -0500, Winterbottom, James wrote: >I guess I don't see an explicit indicator being required. >If the proxy needs it for routing, and it can't get access to it, then >the call will fail. the call won't fail, that session request will receive an error, one that hopefully has enough information in it for the sending UAC to recover the session establishment, and send a new request with altered characteristics - hopefully that will not error this time. The user will likely not notice anything unless the call attempt is ultimately rejected. call me picky. >If the end-point can't get access to it, then the result is application >dependent. > > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > > Sent: Tuesday, 23 May 2006 12:39 AM > > To: Winterbottom, James; Brian Rosen; Hannes Tschofenig; sip@ietf.org; > > geopriv@ietf.org > > Subject: AW: [Geopriv] Explicit Indication of Location Object Consumer > > > > Hi James, > > > > > I am inclined to agree with Brian here. > > > > > > I am not sure why a proxy would just pickout a location URI and > > > de-reference it unless the proxy needed to use it in some way >anyway. > > > Perhaps the example is not such a good one. Hannes do you > > > have something > > > more concrete in mind? > > > > The location conveyance draft has emergency and non-emergency > > applications in mind. > > With emergency calls you want the proxy and the PSAP (as the other end > > of the call) to process the location objects. > > For non-emergency applications you either might want the proxy (for > > location-based routing or the end host to process the LO; or even >both). > > So, do you think there is no need to tell which entity should process > > it? > > > > Ciao > > Hannes > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Monday, 22 May 2006 11:05 AM > > > > To: 'Hannes Tschofenig'; sip@ietf.org; geopriv@ietf.org > > > > Subject: RE: [Geopriv] Explicit Indication of Location > > > Object Consumer > > > > > > > > I would say no. If the location is not needed by proxies, then I > > > would > > > > say > > > > you MUST protect it (S/MIME), or it will not be private. > > > > > > > > If you have to route on it (emergency or otherwise), then > > > you have to > > > send > > > > it with TLS, and the proxies can see it. > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Sunday, May 21, 2006 7:40 AM > > > > To: sip@ietf.org; geopriv@ietf.org > > > > Subject: [Geopriv] Explicit Indication of Location Object Consumer > > > > > > > > Hi James > > > > Hi Brian, > > > > > > > > do you plan to put additional info into the SIP message to >indicate > > > who > > > > should consume the Location Object (explicity rather than implicit > > > info)? > > > > > > > > Here is an example: Assume that SIP UA Alice wants to give Bob > > > location > > > > information (via reference). Now, Alice could easily > > > indicate that it > > > > wants Bob to resolve the reference and to process the > > > location object. > > > > Stating this explicitly would prevent proxies to resolve it and to > > > > process the location object. > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 10:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXmf-0004UL-TV; Tue, 23 May 2006 10:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXmd-0004RF-NA for sip@ietf.org; Tue, 23 May 2006 10:22:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXmc-0001H2-Av for sip@ietf.org; Tue, 23 May 2006 10:22:51 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 07:22:50 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="28709225:sNHT25339884" 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 k4NEMnvF020851 for ; Tue, 23 May 2006 10:22:49 -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.211); Tue, 23 May 2006 10:22:49 -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] Comments on draft-audet-sip-sips-guidelines Date: Tue, 23 May 2006 10:22:48 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6206@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines Thread-Index: AcZ+CBAnBDlEtlNrQTekst5NXqCDCQAamaTw From: "Michael Hammer \(mhammer\)" To: "Cullen Jennings \(fluffy\)" , "IETF SIP List" X-OriginalArrivalTime: 23 May 2006 14:22:49.0668 (UTC) FILETIME=[5EB23040:01C67E74] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Cullen, There seems to be a dichotomy here between what could be termed "best effort" security and "lock icon" security. Given the weak link nature of the former provided by sips, perhaps it might be useful to define a new mode of operation for the latter, rather than try to reform the already implemented former mode. For example, the new mode could require that only redirect servers be used so that the UAC and UAS (no B2BUAs allowed) be able to establish a direct signaling connection over TLS. Of course there would be other details of such an architecture to work out, but at least this would put a stake in the ground for what is needed to give end-users a true "lock icon" option. Mike > -----Original Message----- > From: Cullen Jennings (fluffy)=20 > Sent: Monday, May 22, 2006 9:12 PM > To: IETF SIP List > Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines >=20 >=20 > I think that we all agree that with sips you never know that=20 > know if one of the proxies cheated and that you do not have=20 > e2e security. =20 > Sure e2e would be better but that's not what sips gives you. >=20 > I imagine that we might all be convinced that IP over Brinks=20 > was equivalently secure to TLS. >=20 > The questions is, can we figure out how to specify SIP well=20 > enough that we allow IP over Brinks and don't end up having=20 > implementers implement something far weaker than TLS on every=20 > hop. My point is, I don't think this is a questions about=20 > absolute level of theoretical security that we can achieve, I=20 > think it is a question about how good we are at writing=20 > specifications for abstract security protocols (such as IP=20 > over Brinks). Given that our previous attempt at specifying=20 > sips clearly had some, ah, small holes in it, I initial gut=20 > feeling is to write something very narrow, simple, and easy=20 > to specify. Then as needs arise for sips to be transported=20 > over something other than TLS, carefully extend the previous=20 > RFC to cover the new secure transports. This could be all=20 > wrong, perhaps we can get the more abstract version tightly specified. >=20 > Cullen >=20 >=20 >=20 > On May 17, 2006, at 3:28 PM, Dean Willis wrote: >=20 > > > > On May 16, 2006, at 7:44 PM, Jonathan Rosenberg wrote: > > > >> > >> I'd propose that, to be useful, sips has to do as it implies - it=20 > >> means that each and every link from UAC to UAS was secure.=20 > This means=20 > >> two things: > >> > >> 1. SIPS requires the usage of TLS at every hop - none of=20 > this weasel=20 > >> words on IPSec > >> > >> 2. there is no upgrading or downgrading, period > >> > > > > So, how do you KNOW that TLS was actually used at each hop? > > > > Until you have a way to KNOW that it was, all you have is a=20 > vague hope=20 > > that the serving proxy to UA link was secured properly, and=20 > no amount=20 > > of "MUST" in the specification is going to change it. You'll have=20 > > added feel-good words to the specification that don't=20 > actually improve=20 > > the security characteristics. > > > > Not only that, but you will have prevented "real deployable=20 > security"=20 > > where some links -- like UA to serving proxy -- are=20 > actually secured=20 > > by something like IMS-IPSEC. Net result, everybody will=20 > just use sip:,=20 > > and the security situation will actually degrade relative=20 > to where it=20 > > is today (where sips: works at least part of the time). > > > > TLS works with HTTP because it works end-to-end, tunneling=20 > through the=20 > > HTTP proxies. If a proxy cheats and acts like a B2BUA for TLS, the=20 > > client can check the cert-name and detect the misbehavior. But with=20 > > sips:, we have no way for the UAC to "check up" on the proxies. > > > > For sips: to give the kind of security assurance you seem=20 > to want, it=20 > > has to work end-to-end "through" the proxies, like https: does. > > > > -- > > 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=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 May 23 10:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXn1-0004iG-ML; Tue, 23 May 2006 10:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXn0-0004iB-3d for sip@ietf.org; Tue, 23 May 2006 10:23:14 -0400 Received: from s1.mailresponder.info ([193.24.237.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiXmx-0001H8-DF for sip@ietf.org; Tue, 23 May 2006 10:23:14 -0400 Received: from moonfish.nero.com (82.98.209.31) by s1.mailresponder.info with MERCUR Mailserver (v4.02.30 ODAtMjQzOS03MTc5) for ; Tue, 23 May 2006 16:22:27 +0200 Received: from smtp.ahead.de (unknown [192.168.1.222]) by moonfish.nero.com (Postfix) with ESMTP id 5743D1D1E3B; Tue, 23 May 2006 16:22:20 +0200 (CEST) Received: from [192.168.10.31] (unknown [192.168.10.31]) by smtp.ahead.de (Postfix) with ESMTP id 95DF12DE92D; Tue, 23 May 2006 16:22:20 +0200 (CEST) Message-ID: <44731A9C.1020505@nero.com> Date: Tue, 23 May 2006 16:22:20 +0200 From: Markus Hofmann User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Nataraju Basavaraju References: <7C85DD08A7ABAF4AB2D3FBE46B034F2589512E@niners.inovate.inovate.com> In-Reply-To: <7C85DD08A7ABAF4AB2D3FBE46B034F2589512E@niners.inovate.inovate.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org, Leonid Fainshtein , sip-implementors@cs.columbia.edu Subject: [Sip] Re: [Sip-implementors] Miss-ordered re-INVITE request X-BeenThere: sip@ietf.org X-Mailman-Version: 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 Nataraju, this is not a offer/answer negotiation because it is a ReINVITE and not an initial INVITE. I think but I am not sure at the moment it is not allowed to send a ReINVITE without SDP. Regards, Markus Nataraju Basavaraju wrote: > Hi Markus, > > If the re-INVITE-1 led to delayed negotiation scenario, I mean > re-INVITE-1 without SDP, then offer/answer negotiation would be > completed only when ACK for re-INVITE-1 is received. Till that time we > can't process any more INVITE requests for offer/answer negotiation... > hence re-INVITE-2 should be rejected by 491 response... > > Note: There could only one offer/answer negotiation happening aty any > point in time... > > Regards, > Nataraju A.B. > > -----Original Message----- > From: Markus Hofmann [mailto:mhofmann@nero.com] > Sent: Tue 5/23/2006 5:56 AM > To: Nataraju Basavaraju > Cc: Leonid Fainshtein; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request > > Hi Nataraju, > >> [ABN] probably we may not be able to handle this way always. asuume the >> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >> been received, the offer/answer negotiation is still open, hence it >> should be rejected by 491 response. > > Where in the RFC 3261? > > Regards, > Markus > > Nataraju Basavaraju wrote: >> comments inline... >> >> Regards, >> Nataraju A.B. >> >> -----Original Message----- >> From: sip-implementors-bounces@cs.columbia.edu on behalf of Markus Hofmann >> Sent: Tue 5/23/2006 4:07 AM >> To: Leonid Fainshtein >> Cc: sip-implementors@cs.columbia.edu >> Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request >> >> Hi Leonid, >> >> in my opinion a 200 OK for the second Re-INVITE should be the right >> answer. The Re-INVITE-1/200 OK transaction is over the ACK transaction >> is started (which I do not see in you example). So it seems that UA-1 >> does not work rfc 3261 conform. But this scenario can happen through >> network problems that an new Re-INVITE-2 is faster as an ACK > (RE-INVITE-1). >> >> If you will never receive an ACK for the Re-INVITE-1 you UA-2 (tries to >> get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I think >> the race condition does not affect the signalling and the the media path. >> >> [ABN] probably we may not be able to handle this way always. asuume the >> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >> been received, the offer/answer negotiation is still open, hence it >> should be rejected by 491 response. >> >> if it is a early media call, re-INVITE-2 could be accepted by 200OK... >> >> Regards, >> Markus >> >> >> Leonid Fainshtein wrote: >>> Hi, >>> >>> Is the following UAS behavior correct? >>> >>> UA-1 UA-2 >>> ------INVITE ---------> >>> <------200 ------------ >>> ------- ACK ----------> >>> ------ re-INVITE-1-----> >>> <------200 ------------ >>> >>> ------ re-INVITE-2-----> >>> <------ 400( with Retry-After header) ---- >>> >>> As you can see, the second re-INVITE arrives to the UAS when the >>> previous re-INVITE transaction is not confirmed yet (ACK is not >>> received). >>> What should UAS do in this situation? Silently ignore re-INVITE2? Reject >>> it with response 400 or 500? >>> Thanks, >>> Leonid >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> The information contained in this message may be confidential to Kodiak >> Networks, Inc. and its subsidiaries and protected from disclosure. If >> this message did not reach the intended recipient, or an employee or >> agent responsible for delivering it to the intended recipient, you are >> hereby informed that any distribution or copying of this communication >> is prohibited. If you have received this communication in error, please >> notify us immediately by replying to the sender of the message and then >> delete the message. Thank you > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 10:33:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXuy-0001EA-1F; Tue, 23 May 2006 10:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiXuv-0001DY-SG for sip@ietf.org; Tue, 23 May 2006 10:31:25 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWvm-0007Uj-Mv for sip@ietf.org; Tue, 23 May 2006 09:28:14 -0400 Received: from mail.kodiaknetworks.com ([12.186.66.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiWj5-0006tz-8N for sip@ietf.org; Tue, 23 May 2006 09:15:08 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [Kodiak Networks] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: normal Priority: normal Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 06:14:54 -0700 Message-ID: <7C85DD08A7ABAF4AB2D3FBE46B034F2589512E@niners.inovate.inovate.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] Miss-ordered re-INVITE request Thread-Index: AcZ+aHciNi4cxfGjRUuwxwPHfVBmqwAAQjLW From: "Nataraju Basavaraju" To: "Markus Hofmann" X-Spam-Score: -2.4 (--) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: sip@ietf.org, Leonid Fainshtein , sip-implementors@cs.columbia.edu Subject: [Sip] RE: [Sip-implementors] Miss-ordered re-INVITE request X-BeenThere: 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="===============1293799921==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1293799921== Content-Transfer-Encoding: 7bit Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67E6A.E16CA08E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67E6A.E16CA08E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Markus,=20 If the re-INVITE-1 led to delayed negotiation scenario, I mean = re-INVITE-1 without SDP, then offer/answer negotiation would be = completed only when ACK for re-INVITE-1 is received. Till that time we = can't process any more INVITE requests for offer/answer negotiation... = hence re-INVITE-2 should be rejected by 491 response... Note: There could only one offer/answer negotiation happening aty any = point in time...=20 Regards, Nataraju A.B. -----Original Message----- From: Markus Hofmann [mailto:mhofmann@nero.com] Sent: Tue 5/23/2006 5:56 AM To: Nataraju Basavaraju Cc: Leonid Fainshtein; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request =20 Hi Nataraju, > [ABN] probably we may not be able to handle this way always. asuume = the > scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is = not > been received, the offer/answer negotiation is still open, hence it > should be rejected by 491 response. Where in the RFC 3261? Regards, Markus Nataraju Basavaraju wrote: > comments inline... >=20 > Regards, > Nataraju A.B. >=20 > -----Original Message----- > From: sip-implementors-bounces@cs.columbia.edu on behalf of Markus = Hofmann > Sent: Tue 5/23/2006 4:07 AM > To: Leonid Fainshtein > Cc: sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request >=20 > Hi Leonid, >=20 > in my opinion a 200 OK for the second Re-INVITE should be the right > answer. The Re-INVITE-1/200 OK transaction is over the ACK transaction > is started (which I do not see in you example). So it seems that UA-1 > does not work rfc 3261 conform. But this scenario can happen through > network problems that an new Re-INVITE-2 is faster as an ACK = (RE-INVITE-1). >=20 > If you will never receive an ACK for the Re-INVITE-1 you UA-2 (tries = to > get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I think > the race condition does not affect the signalling and the the media = path. >=20 > [ABN] probably we may not be able to handle this way always. asuume = the > scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is = not > been received, the offer/answer negotiation is still open, hence it > should be rejected by 491 response. >=20 > if it is a early media call, re-INVITE-2 could be accepted by 200OK... >=20 > Regards, > Markus >=20 >=20 > Leonid Fainshtein wrote: >> Hi, >> >> Is the following UAS behavior correct? >> >> UA-1 UA-2 >> ------INVITE ---------> >> <------200 ------------ >> ------- ACK ----------> >> ------ re-INVITE-1-----> >> <------200 ------------ >> >> ------ re-INVITE-2-----> >> <------ 400( with Retry-After header) ---- >> >> As you can see, the second re-INVITE arrives to the UAS when the >> previous re-INVITE transaction is not confirmed yet (ACK is not >> received). >> What should UAS do in this situation? Silently ignore re-INVITE2? = Reject >> it with response 400 or 500? >> Thanks, >> Leonid >> >> _______________________________________________ >> 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 >=20 >=20 > The information contained in this message may be confidential to = Kodiak > Networks, Inc. and its subsidiaries and protected from disclosure. If > this message did not reach the intended recipient, or an employee or > agent responsible for delivering it to the intended recipient, you are > hereby informed that any distribution or copying of this communication > is prohibited. If you have received this communication in error, = please > notify us immediately by replying to the sender of the message and = then > delete the message. Thank you ------_=_NextPart_001_01C67E6A.E16CA08E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip-implementors] Miss-ordered re-INVITE request

Hi Markus,

If the re-INVITE-1 led to delayed negotiation scenario, I mean = re-INVITE-1 without SDP, then offer/answer negotiation would be = completed only when ACK for re-INVITE-1 is received. Till that time we = can't process any more INVITE requests for offer/answer negotiation... = hence re-INVITE-2 should be rejected by 491 response...

Note: There could only one offer/answer negotiation happening aty any = point in time...

Regards,
Nataraju A.B.

-----Original Message-----
From: Markus Hofmann [mailto:mhofmann@nero.com]
Sent: Tue 5/23/2006 5:56 AM
To: Nataraju Basavaraju
Cc: Leonid Fainshtein; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request

Hi Nataraju,

> [ABN] probably we may not be able to handle this way always. asuume = the
> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is = not
> been received, the offer/answer negotiation is still open, hence = it
> should be rejected by 491 response.

Where in the RFC 3261?

Regards,
  Markus

Nataraju Basavaraju wrote:
> comments inline...
>
> Regards,
> Nataraju A.B.
>
> -----Original Message-----
> From: sip-implementors-bounces@cs.columbia.edu on behalf of Markus = Hofmann
> Sent: Tue 5/23/2006 4:07 AM
> To: Leonid Fainshtein
> Cc: sip-implementors@cs.columbia.edu
> Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request
>
> Hi Leonid,
>
> in my opinion a 200 OK for the second Re-INVITE should be the = right
> answer. The Re-INVITE-1/200 OK transaction is over the ACK = transaction
> is started (which I do not see in you example). So it seems that = UA-1
> does not work rfc 3261 conform. But this scenario can happen = through
> network problems that an new Re-INVITE-2 is faster as an ACK = (RE-INVITE-1).
>
> If you will never receive an ACK for the Re-INVITE-1 you UA-2 = (tries to
> get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I = think
> the race condition does not affect the signalling and the the media = path.
>
> [ABN] probably we may not be able to handle this way always. asuume = the
> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is = not
> been received, the offer/answer negotiation is still open, hence = it
> should be rejected by 491 response.
>
> if it is a early media call, re-INVITE-2 could be accepted by = 200OK...
>
> Regards,
>   Markus
>
>
> Leonid Fainshtein wrote:
>> Hi,
>>
>> Is the following UAS behavior correct?
>>
>> = UA-1           &nb= sp;       UA-2
>> ------INVITE --------->
>> <------200 ------------
>> ------- ACK ---------->
>> ------ re-INVITE-1----->
>> <------200 ------------
>>
>> ------ re-INVITE-2----->
>> <------ 400( with Retry-After header) ----
>>
>> As you can see, the second re-INVITE arrives to the UAS when = the
>> previous re-INVITE transaction is not confirmed yet (ACK is = not
>> received).
>> What should UAS do in this situation? Silently ignore = re-INVITE2? Reject
>> it with response 400 or 500?
>> Thanks,
>> Leonid
>>
>> _______________________________________________
>> 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 >
>
>
>
> The information contained in this message may be confidential to = Kodiak
> Networks, Inc. and its subsidiaries and protected from disclosure. = If
> this message did not reach the intended recipient, or an employee = or
> agent responsible for delivering it to the intended recipient, you = are
> hereby informed that any distribution or copying of this = communication
> is prohibited. If you have received this communication in error, = please
> notify us immediately by replying to the sender of the message and = then
> delete the message. Thank you

------_=_NextPart_001_01C67E6A.E16CA08E-- --===============1293799921== 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 --===============1293799921==-- From sip-bounces@ietf.org Tue May 23 12:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZJi-0002MV-TX; Tue, 23 May 2006 12:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZJh-0002BR-8H for sip@ietf.org; Tue, 23 May 2006 12:01:05 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZJf-0005rF-Jv for sip@ietf.org; Tue, 23 May 2006 12:01:05 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 23 May 2006 09:01:02 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="1811315212:sNHT137081386" 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/8.12.11) with ESMTP id k4NG12GA032706; Tue, 23 May 2006 09:01:02 -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 k4NG10sH027909; Tue, 23 May 2006 09:01:01 -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.211); Tue, 23 May 2006 12:01:00 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 12:01:00 -0400 Message-ID: <447331BB.9030600@cisco.com> Date: Tue, 23 May 2006 12:00:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Markus Hofmann Subject: Re: [Sip] Re: [Sip-implementors] Miss-ordered re-INVITE request References: <7C85DD08A7ABAF4AB2D3FBE46B034F2589512E@niners.inovate.inovate.com> <44731A9C.1020505@nero.com> In-Reply-To: <44731A9C.1020505@nero.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2006 16:01:00.0287 (UTC) FILETIME=[15C750F0:01C67E82] DKIM-Signature: a=rsa-sha1; q=dns; l=4962; t=1148400062; x=1149264062; c=relaxed/simple; s=sjdkim5001; 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]=20Miss-ordered=20re-INVITE=20 request; X=v=3Dcisco.com=3B=20h=3DzUD4uor8rQ4xnqIeV1duiMOgbc0=3D; b=fr6W458N5NVkd/QQfVse/vcg29f1N4/1JIn93CBQj97qPz+pSO+PvGJ4A+BN8fHkaBefccde El9q/vLblm85a4kvXrgWuzw70sTvm9UqSWo8/CNiAjlSCwSwESk72hwp; 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: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, Leonid Fainshtein , 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 Markus Hofmann wrote: > Hi Nataraju, > > this is not a offer/answer negotiation because it is a ReINVITE and not > an initial INVITE. > > I think but I am not sure at the moment it is not allowed to send a > ReINVITE without SDP. It definitely *is* legal to send a reINVITE without SDP. Its a key component of many B2BUA 3pcc call flows. Paul > Regards, > Markus > > Nataraju Basavaraju wrote: >> Hi Markus, >> >> If the re-INVITE-1 led to delayed negotiation scenario, I mean >> re-INVITE-1 without SDP, then offer/answer negotiation would be >> completed only when ACK for re-INVITE-1 is received. Till that time we >> can't process any more INVITE requests for offer/answer negotiation... >> hence re-INVITE-2 should be rejected by 491 response... >> >> Note: There could only one offer/answer negotiation happening aty any >> point in time... >> >> Regards, >> Nataraju A.B. >> >> -----Original Message----- >> From: Markus Hofmann [mailto:mhofmann@nero.com] >> Sent: Tue 5/23/2006 5:56 AM >> To: Nataraju Basavaraju >> Cc: Leonid Fainshtein; sip-implementors@cs.columbia.edu >> Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request >> >> Hi Nataraju, >> >>> [ABN] probably we may not be able to handle this way always. asuume the >>> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >>> been received, the offer/answer negotiation is still open, hence it >>> should be rejected by 491 response. >> Where in the RFC 3261? >> >> Regards, >> Markus >> >> Nataraju Basavaraju wrote: >>> comments inline... >>> >>> Regards, >>> Nataraju A.B. >>> >>> -----Original Message----- >>> From: sip-implementors-bounces@cs.columbia.edu on behalf of Markus Hofmann >>> Sent: Tue 5/23/2006 4:07 AM >>> To: Leonid Fainshtein >>> Cc: sip-implementors@cs.columbia.edu >>> Subject: Re: [Sip-implementors] Miss-ordered re-INVITE request >>> >>> Hi Leonid, >>> >>> in my opinion a 200 OK for the second Re-INVITE should be the right >>> answer. The Re-INVITE-1/200 OK transaction is over the ACK transaction >>> is started (which I do not see in you example). So it seems that UA-1 >>> does not work rfc 3261 conform. But this scenario can happen through >>> network problems that an new Re-INVITE-2 is faster as an ACK >> (RE-INVITE-1). >>> If you will never receive an ACK for the Re-INVITE-1 you UA-2 (tries to >>> get an ACK be retransmit 200 OK (Re-INVIT-1) must send a BYE. I think >>> the race condition does not affect the signalling and the the media path. >>> >>> [ABN] probably we may not be able to handle this way always. asuume the >>> scenario, delayed negotiation scenarion with re-INVITE-1 and ACK is not >>> been received, the offer/answer negotiation is still open, hence it >>> should be rejected by 491 response. >>> >>> if it is a early media call, re-INVITE-2 could be accepted by 200OK... >>> >>> Regards, >>> Markus >>> >>> >>> Leonid Fainshtein wrote: >>>> Hi, >>>> >>>> Is the following UAS behavior correct? >>>> >>>> UA-1 UA-2 >>>> ------INVITE ---------> >>>> <------200 ------------ >>>> ------- ACK ----------> >>>> ------ re-INVITE-1-----> >>>> <------200 ------------ >>>> >>>> ------ re-INVITE-2-----> >>>> <------ 400( with Retry-After header) ---- >>>> >>>> As you can see, the second re-INVITE arrives to the UAS when the >>>> previous re-INVITE transaction is not confirmed yet (ACK is not >>>> received). >>>> What should UAS do in this situation? Silently ignore re-INVITE2? Reject >>>> it with response 400 or 500? >>>> Thanks, >>>> Leonid >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> The information contained in this message may be confidential to Kodiak >>> Networks, Inc. and its subsidiaries and protected from disclosure. If >>> this message did not reach the intended recipient, or an employee or >>> agent responsible for delivering it to the intended recipient, you are >>> hereby informed that any distribution or copying of this communication >>> is prohibited. If you have received this communication in error, please >>> notify us immediately by replying to the sender of the message and then >>> delete the message. Thank you >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 23 13:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaTS-00078X-2h; Tue, 23 May 2006 13:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaTR-00078S-BK for sip@ietf.org; Tue, 23 May 2006 13:15:13 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaTP-0000jo-T0 for sip@ietf.org; Tue, 23 May 2006 13:15:13 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k4NHFAld013403 for ; Tue, 23 May 2006 11:15:11 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 May 2006 11:15:10 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-outbound-03/routing mid-dialog requests Thread-Index: AcZ+jGyrqNtePO9eSZiy5imz18FwWg== From: "Kevin Johns" To: X-Approved: ondar X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [Sip] draft-ietf-sip-outbound-03/routing mid-dialog requests X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0483797554==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0483797554== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67E8C.728DC72D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67E8C.728DC72D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 5.3 of draft-ietf-sip-outbound-03 states: "Note that techniques to ensure that mid-dialog requests are routed over an existing flow are out of scope and therefore not part of this specification. However, an approach such as having the Edge Proxy Record-Route with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow." =20 Record-Routing at the Edge Proxy seems like the right thing to do as it parallels the approach used during Registration (adding a flow token to the PATH header) for routing of dialog initiating requests. The sticking point with this approach is that once the Edge Proxy record routes itself, the route set cannot be updated and Edge Proxy failover is compromised. The primary reason being that the algorithms proposed in draft-ietf-sip-outbound-03 for generating the flow token result in a flow token which is only understandable only to the Edge Proxy which generated it. Thus, mid-dialog Edge Proxy failover is complicated as the backup Edge Proxy will not understand the flow token (unless the primary Edge Proxy shares such state data to the backup Edge Proxy) and cannot identify the flow to forward the request on. =20 One approach to addressing this issue is to use a token value that has meaning to both Edge Proxies without requiring the sharing of state data. To me, the most obvious value is to use the instance ID of the UA as the flow token. Based on the definition of the instance ID, it is expected to be globally unique so collisions are not expected. The UA includes the instance ID in all registrations and thus both Edge Proxies (primary and secondary) would see this value and can associate it with the flow. =20 I am planning on authoring an ID that covers this and would like to see if anyone has any feedback on the proposed solution. =20 Kevin =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_01C67E8C.728DC72D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 5.3 of=20 draft-ietf-sip-outbound-03 states:
"Note=20 that techniques to ensure that mid-dialog requests are routed over an = existing=20 flow are out of scope and therefore not part of this specification. = However, an=20 approach such as having the Edge Proxy Record-Route with a flow token is = one way=20 to ensure that mid-dialog requests are routed over the correct = flow."
 
Record-Routing at the=20 Edge Proxy seems like the right thing to do as it parallels the = approach=20 used during Registration (adding a flow token to the PATH header) for = routing of=20 dialog initiating requests. The=20 sticking point with this approach=20 is that once = the Edge Proxy record routes itself, the route=20 set cannot be updated and Edge=20 Proxy failover=20 is compromised. = The primary reason being that the=20 algorithms proposed in draft-ietf-sip-outbound-03 for generating the flow token result = in a flow=20 token which is only understandable only=20 to the Edge Proxy which generated it. Thus, mid-dialog = Edge=20 Proxy failover is complicated as the backup Edge Proxy will not = understand the=20 flow token (unless the primary Edge Proxy shares such state data to = the=20 backup Edge Proxy) and cannot identify the flow to forward the request=20 on.
 
One approach to addressing this issue is to = use a=20 token value that has meaning = to=20 both Edge Proxies without=20 requiring the sharing of state data. To me, the most obvious value is to use the instance ID of the UA as the flow token. Based on the definition of the instance ID, = it is=20 expected to be globally unique so collisions are not expected. The UA = includes=20 the instance ID in all registrations and thus both Edge Proxies (primary = and=20 secondary) would see this value and can associate it with the=20 flow.
 
I am planning on authoring an ID that covers = this and=20 would like to see if anyone has any feedback on the proposed=20 solution.
 
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_01C67E8C.728DC72D-- --===============0483797554== 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 --===============0483797554==-- From sip-bounces@ietf.org Tue May 23 17:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiefo-000582-ID; Tue, 23 May 2006 17:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiefn-00057w-CQ for sip@ietf.org; Tue, 23 May 2006 17:44:15 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiefl-0005tl-PU for sip@ietf.org; Tue, 23 May 2006 17:44:15 -0400 Received: (qmail 731 invoked by uid 0); 23 May 2006 21:44:00 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 May 2006 21:44:00 -0000 Message-ID: <009001c67eb2$02ab5860$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? Date: Tue, 23 May 2006 23:44:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Erkki, Technically, I believe we could make both approaches work. Personally I find the TXT associated with SRV approach more intuitive, because 'outbound support' to me is a property of individual servers. You could also define 'outbound support' as a service supported by a farm of proxies (which is basically what you do with the NAPTR approach). For a single property both are more or less equivalent, but if you consider that in the future we may want to add a second property 'X' (and third 'Y' and fourth 'Z') then the TXT approach seems easier to extend, and thus more future proof. In a situation where you would have one domain serving NAPTR records pointing to SRV records in another domain, if you associate outbound support with NAPTR records it would imply that changes in the server park require DNS configuration changes in both domains. Not sure how common such a setup is, but on paper this type of referential integrity seems cumbersome to maintain. >From a technical perspective, surely we can come up with solutions for all of the (-) points mentioned below. For example, you could assign a lower priority to SRV records with an associated TXT record indicating that the server supports outbound, and have clients interpret outbound support as a '+2' bonus to the weight (some people might consider this a 'hack' though...) Regards, Jeroen ----- Original Message ----- From: To: Cc: Sent: Tuesday, May 23, 2006 9:49 AM Subject: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? Hi ! I have finally got some time to study the SIP Outbound autodiscovery further based on the comments given to the I-D. The choice betweeen DNS NAPTR and TXT records seems to be a difficult one. The two options proposed are as follows: A. Define new values for NAPTR service field as "SIP-O+D2X", where X will be replaced with a letter indicating transport protocol. Service "SIP-O" means support for SIP Outbound, while "SIPS-O" indicates additional TLS/SIPS URI support. B. Associate DNS TXT records with the SRV records for servers supporting SIP Outbound. Those TXT records would contain a value like "sip-outbound" when server supports SIP Outbound. Further on define a new "t" flag for SRV records to give a hint to the server to return all related TXT record as additional information. The benefits (+) and drawbacks (-) of these solutions seem to be as follows: A. NAPTR records + When responding to one NAPTR query the DNS server typically returns not only the NAPTR records but also the related SRV and address records as the NAPTR and SRV RFCs already suggest doing so. Thus with a single DNS query the UA would get all the needed information. + Using different NAPTR service types for SIP Outbound would make it straightforward for an operator to divide its servers to two farms: Servers with SIP Outbound to be used by clients of the service provider and servers without SIP Outbound to be used by external UAs. As the external UAs would NOT need SIP Outbound, when they resolve the SIP URI of callee in the conventional (RFC 3263) way, the result would be those servers without SIP Outbound support, which is the desired outcome. - Both the UA and DNS server would have to support NAPTR RRs, which is not always the case currently. Some DNS service providers do not allow NAPTR RRs and the UA support is not always there. - The number of NAPTR service types for SIP would double (from current five to ten) and as indicated in RFC 3486, this is not a scalable way of using DNS. If in the future yet another combination would be needed to double the number of NAPTR service types for SIP, then there would be 20 types, which sounds excessive. B. TXT records + There are no combinatorial problems by introducing new flags into TXT records, since any new flag is just another text string to be added amongst the others. + Adding TXT RR support for UAs does not seem a very challenging task, whether or not the UA already supports NAPTR RRs. - There is no built-in way for the service provider to prevent the clients of other service providers to resolve SIP URIs to proxies supporting SIP Outbound (aimed to be used only by the local clients as outbound proxies for NAT traversal). - If the server does not understand or obey the new "t" flag of SRV RR, then the UA has to separately query the TXT records for every SRV record it tries to use. This might lead to N x TXT RR queries before the SIP server has finally been located. - Both the UA and DNS server would have to support TXT RRs, however even those are not allowed by some DNS service providers even if the servers might already support those almost universally. For the pure technical point of view I am currently slightly inclined towards using TXT records, but NAPTR also has its advantages. However I am worried about the fact that TXT records are almost too "general purpose" and I am not aware of any other standarized solutions relying only on TXT records: - SPF uses TXT records only as a fallback solution in case where the DNS server does not yet support SPF records, the same seems to apply to DKIM RRs. However for SIP Outbound, defining new RR types for one single boolean flag is not a feasible solution. - For DNS-SD there is only an expired I-D and there seems to be no movement to get it approved as an RFC. Also this kind of comments would make me doubt if the solution based on TXT records is eventually acceptable (even if the use of TXT records in SIP Outbound case would be straightforward): > A word of caution: use of TXT records will get you an > earful from the IAB. The entire area is a huge tangle > and you need to be extremely cautious about how you use > TXT records. So I would like to get your comments or 'hum' for one option or another. I have already prepared a second version of the I-D with a new way of using SRV records to find the target host for the backup flow, based on the comments received for this subject. Now the final issue before publishing this edition is whether to use NAPTR and TXT records to indicate support for SIP Outbound. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 23 17:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FieoP-0000KC-TT; Tue, 23 May 2006 17:53:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FieoN-0000K0-TE for sip@ietf.org; Tue, 23 May 2006 17:53:07 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FieoM-0006Kh-Gg for sip@ietf.org; Tue, 23 May 2006 17:53:07 -0400 Received: (qmail 10172 invoked by uid 0); 23 May 2006 21:53:02 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 May 2006 21:53:02 -0000 Message-ID: <009f01c67eb3$459164c0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Tue, 23 May 2006 23:53:05 +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.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK X-BeenThere: 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="===============0780593295==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0780593295== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01C67EC4.09026700" This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C67EC4.09026700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Table 2 in RFC3261 disallows Proxy-Require in ACK requests (i.e. it has = a '-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on the = ability to include a Proxy-Require in an ACK to a 2xx response, although = they are not very explicit on this. RFC3261 explicitly says that Proxy-Require MUST NOT be used for CANCEL = or ACK to non-2xx (which are hop by hop), but I believe the intention = was to allow it for ACK to 2xx. Therefore, table 2 should say 'o' here Regards, Jeroen ------=_NextPart_000_009C_01C67EC4.09026700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Table 2 in RFC3261 disallows = Proxy-Require in ACK=20 requests (i.e. it has a '-'). Some standards (e.g. RFC3323, RFC3329) = seem to=20 rely on the ability to include a Proxy-Require in an ACK to a 2xx = response,=20 although they are not very explicit on this.
 
RFC3261 explicitly says that = Proxy-Require MUST NOT=20 be used for CANCEL or ACK to non-2xx (which are hop by hop), but I = believe=20 the intention was to allow it for ACK to 2xx. Therefore, table 2 should = say 'o'=20 here
 
Regards,
 
Jeroen
------=_NextPart_000_009C_01C67EC4.09026700-- --===============0780593295== 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 --===============0780593295==-- From sip-bounces@ietf.org Tue May 23 20:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigtT-0005Uo-3w; Tue, 23 May 2006 20:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FigtR-0005Uj-RB for sip@ietf.org; Tue, 23 May 2006 20:06:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FigtO-0003n2-Hq for sip@ietf.org; Tue, 23 May 2006 20:06:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 May 2006 17:06:26 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,162,1146466800"; d="scan'208"; a="28766327:sNHT22173920" 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 k4O06PvF028819; Tue, 23 May 2006 20:06: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.211); Tue, 23 May 2006 20:06:25 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 20:06:25 -0400 Message-ID: <4473A381.7070609@cisco.com> Date: Tue, 23 May 2006 20:06:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK References: <009f01c67eb3$459164c0$31713b51@BEMBUSTER> In-Reply-To: <009f01c67eb3$459164c0$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 00:06:25.0513 (UTC) FILETIME=[E5C41D90:01C67EC5] 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 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't see how this makes any sense. Proxy-Require only makes sense if a proxy that doesn't support the option can reject the request. Since ACK gets no response there is no way to reject it. Paul Jeroen van Bemmel wrote: > Table 2 in RFC3261 disallows Proxy-Require in ACK requests (i.e. it has > a '-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on the > ability to include a Proxy-Require in an ACK to a 2xx response, although > they are not very explicit on this. > > RFC3261 explicitly says that Proxy-Require MUST NOT be used for CANCEL > or ACK to non-2xx (which are hop by hop), but I believe the intention > was to allow it for ACK to 2xx. Therefore, table 2 should say 'o' here > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 23 23:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FikOo-0006eq-UR; Tue, 23 May 2006 23:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FikOm-0006ek-Tj for sip@ietf.org; Tue, 23 May 2006 23:51:04 -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 1FikOl-0005Ju-ID for sip@ietf.org; Tue, 23 May 2006 23:51:04 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 May 2006 20:51:03 -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/8.12.11) with ESMTP id k4O3p3cP031290; Tue, 23 May 2006 20:51:03 -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 k4O3p2B7027703; Tue, 23 May 2006 20:51: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, 23 May 2006 20:51:02 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 20:51:01 -0700 Message-Id: <4.3.2.7.2.20060523224943.0363f1b8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 May 2006 22:51:00 -0500 To: Paul Kyzivat , Jeroen van Bemmel From: "James M. Polk" Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK In-Reply-To: <4473A381.7070609@cisco.com> References: <009f01c67eb3$459164c0$31713b51@BEMBUSTER> <009f01c67eb3$459164c0$31713b51@BEMBUSTER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 May 2006 03:51:02.0156 (UTC) FILETIME=[4678A4C0:01C67EE5] DKIM-Signature: a=rsa-sha1; q=dns; l=1602; t=1148442663; x=1149306663; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Sip]=20Bug=20in=20RFC3261=3A=20Proxy-Require=20not=20allowed=20 in=20ACK; X=v=3Dcisco.com=3B=20h=3DEtHBfGkdJNY2X6lY/mM5k/XXQJ4=3D; b=o0CsKi0n9nrFXdU0Fdj9Kedm90s8xdIRbzLWXzsT4OmiblkiCYp4wC8BgKZjea5aE7nUxoxY astaD3Yvn8d7kVXi97mHV/dt/zLeFoxXoBs4V59oB4vREoZ6wYS92Dbz; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 At 08:06 PM 5/23/2006 -0400, Paul Kyzivat wrote: >I don't see how this makes any sense. Proxy-Require only makes sense if a >proxy that doesn't support the option can reject the request. Since ACK >gets no response there is no way to reject it. ...there is no reason to reject it (because nothing is the result). > Paul > >Jeroen van Bemmel wrote: >>Table 2 in RFC3261 disallows Proxy-Require in ACK requests (i.e. it has a >>'-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on the ability >>to include a Proxy-Require in an ACK to a 2xx response, although they are >>not very explicit on this. >> >>RFC3261 explicitly says that Proxy-Require MUST NOT be used for CANCEL or >>ACK to non-2xx (which are hop by hop), but I believe the intention was to >>allow it for ACK to 2xx. Therefore, table 2 should say 'o' here >> >>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 > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 24 02:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fin7Z-0006Dr-CR; Wed, 24 May 2006 02:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fin7X-0006D0-7h for sip@ietf.org; Wed, 24 May 2006 02:45:27 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FimvD-0004ZD-Tn for sip@ietf.org; Wed, 24 May 2006 02:32:45 -0400 Received: (qmail 5960 invoked by uid 0); 24 May 2006 06:32:41 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 May 2006 06:32:41 -0000 Message-ID: <002701c67efb$dca6fc60$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Paul Kyzivat" References: <009f01c67eb3$459164c0$31713b51@BEMBUSTER> <4473A381.7070609@cisco.com> Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Date: Wed, 24 May 2006 08:32:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Paul, At the very least, the current table is confusing with respect to the following text in section 8.2.2.3: "An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request." Although this says "MUST contain *only*" and not "MUST contain", it seems to suggest that it is at least allowed to include a Proxy-Require in an ACK to 2xx. BTW, now that I notice: also the entry for 'Require' currently says '-' for ACK >I don't see how this makes any sense. Proxy-Require only makes sense if a >proxy that doesn't support the option can reject the request. Since ACK >gets no response there is no way to reject it. > > Paul In some cases 'Proxy-Require' is used to request certain behavior / processing from a proxy. For example in RFC3323, if "Privacy: header" is added to an ACK, the UA SHOULD add also a 'Proxy-Require: privacy' to ensure that the target supports this extension. Although the proxy would not be able to respond to the ACK, an element not supporting the extension should probably discard the ACK rather than forwarding it (without stripping the Via header as required by the extension in this case). I agree that proxy behavior for 'Proxy-Require' in ACK is different from Proxy-Require in normal requests (again: not clearly described, I'm speculating that the ACK should be dropped if not supported here). So either we disallow Proxy-Require / Require in ACK and update the text in 8.2.2.3, or we modify table 2/3 and clarify proxy/UAS behavior for ACK containing these headers Regards, Jeroen > > Jeroen van Bemmel wrote: >> Table 2 in RFC3261 disallows Proxy-Require in ACK requests (i.e. it has a >> '-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on the ability >> to include a Proxy-Require in an ACK to a 2xx response, although they are >> not very explicit on this. >> RFC3261 explicitly says that Proxy-Require MUST NOT be used for CANCEL >> or ACK to non-2xx (which are hop by hop), but I believe the intention was >> to allow it for ACK to 2xx. Therefore, table 2 should say 'o' here >> 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 24 02:48:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fin7X-0006DT-Vl; Wed, 24 May 2006 02:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fin7R-0006Br-Ri for sip@ietf.org; Wed, 24 May 2006 02:45:21 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fimyw-0004xJ-CI for sip@ietf.org; Wed, 24 May 2006 02:36:36 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 1FCAD3BEC0; Wed, 24 May 2006 08:36:15 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17001-03-44; Wed, 24 May 2006 08:36:14 +0200 (CEST) Received: from dhcp-wavelan-vo-10.publik.su.se (dhcp-wavelan-vo-10.publik.su.se [193.11.30.10]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 2B96A3BE4F; Wed, 24 May 2006 08:36:11 +0200 (CEST) From: Fredrik Thulin To: Erkki.Koivusalo@nokia.com Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or TXT records ? Date: Wed, 24 May 2006 08:36:06 +0200 User-Agent: KMail/1.9.1 References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605240836.06076.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.628 tagged_above=-99 required=7 tests=[AWL=0.037, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Tuesday 23 May 2006 09:49, Erkki.Koivusalo@nokia.com wrote: ... > So I would like to get your comments or 'hum' for one option > or another. I hum loudly against TXT. The extendibility others have talked about will surely lead to a great mess, IMO. Maybe it isn't so unreasonable to define new values for NAPTR service, since the old ones are for SIP and the new ones are for SIP+STUN+more service? If it is, then perhaps the idea with DNS based provisioning of outbound SIP service isn't a good idea after all... /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 24 03:40:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finwg-0007OV-S0; Wed, 24 May 2006 03:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finvf-0006uU-8K for sip@ietf.org; Wed, 24 May 2006 03:37:15 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Finmj-0007Ps-K8 for sip@ietf.org; Wed, 24 May 2006 03:28:02 -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: Wed, 24 May 2006 09:27:46 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798019F9012@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of content indirection mechanism draft Thread-Index: AcZ/A43PplHzjOI3SvaF2/mYKLT3Iw== From: To: X-OriginalArrivalTime: 24 May 2006 07:27:48.0982 (UTC) FILETIME=[8F24C960:01C67F03] X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Status of content indirection mechanism 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: , Errors-To: sip-bounces@ietf.org Hi all, I've one simple question regarding status of draft-ietf-sip-content-indirect-mech-05. It has expired a year ago and it is still in rfc editor queue. Is there planned some action with that draft (rfc release)? br, Martin Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 599 096 022 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.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 May 24 03:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finyt-0007tJ-KE; Wed, 24 May 2006 03:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Finys-0007tE-5J for sip@ietf.org; Wed, 24 May 2006 03:40:34 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Finyq-000892-MY for sip@ietf.org; Wed, 24 May 2006 03:40:34 -0400 Received: (qmail 5100 invoked by uid 0); 24 May 2006 07:40:27 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 May 2006 07:40:27 -0000 Message-ID: <007c01c67f05$55b46e90$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Fredrik Thulin" , References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> <200605240836.06076.ft@it.su.se> Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Wed, 24 May 2006 09:40:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Fredrik, I tend to agree with you - TXT could very well become a can of wurms here Going back to the original problem: we wanted to have a way to discover outbound support. One scenario is that a client discovers a SIP outbound proxy through a DHCP option, resulting in an IP address or a DNS hostname. One thing to note here is that current clients in general don't have a way to lookup or prefer proxies with specific features. For example, they cannot choose RFC3261 proxies over non-RFC3261 proxies; they do not know in advance whether the discovered host(s) perform loose routing. For loose routing this is not a big problem; a client adds a 'lr' parameter anyway, and if it turns out to be a non-RFC3261 proxy, it will find out through the Record-Route header (or Path or Service-Route). And there are more cases like this (e.g. RFC3329 support, privacy services, ...) My suggestion for TXT was rooted in the expectation that we'll soon find ourselves with a need for discovery of other features too. The proposed NAPTR approach does not offer this. On the other hand, like Fredrik indicates - there is a danger of 'a great mess' Consider the following 2 options: A) Use the hostname / IP discovered through DHCP as a key for DNS lookup B) Extend the DHCP options used for SIP server discovery, to contain more than only the hostname A) What if we would simply take the DNS name (or IP address) discovered through DHCP, and feed it to a new NAPTR service - say H2U, for hostname-to-URI. This could perform a similar rewrite as DNS ENUM does, and return a sip: URI including flag parameters that indicate supported features (like 'lr' for loose routing, and 'ob' for outbound support). So for example: through DHCP client discovers 'proxy.example.com' and does a NAPTR lookup $ORIGIN proxy.example.com.sip.dhcp. IN NAPTR 100 10 "u" "sip+H2U" "!^.*$!sip:proxy.example.com;lr;ob!" >From this point on, things would be the same as if this URI had been provisioned manually. B) What seems to be causing this pain in the first place, is the limitations imposed by current DHCP options. Therefore another approach could be to define a new or extended DHCP option, supporting more than just the IP address or hostname (i.e. include outbound support flag there, and preferrably some mechanism for future options). Regards, Jeroen ----- Original Message ----- From: "Fredrik Thulin" To: Cc: Sent: Wednesday, May 24, 2006 8:36 AM Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? > On Tuesday 23 May 2006 09:49, Erkki.Koivusalo@nokia.com wrote: > ... >> So I would like to get your comments or 'hum' for one option >> or another. > > I hum loudly against TXT. The extendibility others have talked about > will surely lead to a great mess, IMO. > > Maybe it isn't so unreasonable to define new values for NAPTR service, > since the old ones are for SIP and the new ones are for SIP+STUN+more > service? If it is, then perhaps the idea with DNS based provisioning of > outbound SIP service isn't a good idea after all... > > /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 Wed May 24 04:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioQK-00080k-UN; Wed, 24 May 2006 04:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FioQJ-0007yv-1P for sip@ietf.org; Wed, 24 May 2006 04:08:55 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FioQH-0001E7-KP for sip@ietf.org; Wed, 24 May 2006 04:08:55 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id AF2D13BE38; Wed, 24 May 2006 10:08:36 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01394-01-42; Wed, 24 May 2006 10:08:35 +0200 (CEST) Received: from dhcp-wavelan-vo-10.publik.su.se (dhcp-wavelan-vo-10.publik.su.se [193.11.30.10]) (using TLSv1 with cipher EXP1024-RC4-SHA (56/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id E4FC33BE2F; Wed, 24 May 2006 10:08:35 +0200 (CEST) From: Fredrik Thulin To: "Jeroen van Bemmel" Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Wed, 24 May 2006 10:08:30 +0200 User-Agent: KMail/1.9.1 References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> <200605240836.06076.ft@it.su.se> <007c01c67f05$55b46e90$31713b51@BEMBUSTER> In-Reply-To: <007c01c67f05$55b46e90$31713b51@BEMBUSTER> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605241008.30836.ft@it.su.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.629 tagged_above=-99 required=7 tests=[AWL=0.036, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Wednesday 24 May 2006 09:40, Jeroen van Bemmel wrote: > Fredrik, > > I tend to agree with you - TXT could very well become a can of wurms > here > > Going back to the original problem: we wanted to have a way to > discover outbound support. One scenario is that a client discovers a > SIP outbound proxy through a DHCP option, resulting in an IP address > or a DNS hostname. First, remember that there are at least two kinds of outbound proxys. 1) The one required by the network you are visiting (wifi hotspot, hotel network etc.). The name of this outbound proxy can only reasonably be found through SIP DHCP options, I'd agree. 2) The one of your own home network. When I'm travelling, I would like to avoid using the visited networks outbound proxy if at all possible, but I _would_ like to register with my own proxys directly so that I can get some reasonable security through TLS to proxys whose certificate I trust. You seem to be talking mostly about the first scenario, and I mostly about the second. I just want to bring them both forward to make sure we don't forget the requirements of others than ourselves. > One thing to note here is that current clients in general don't have > a way to lookup or prefer proxies with specific features. ... Well put. ... > Consider the following 2 options: > A) Use the hostname / IP discovered through DHCP as a key for DNS > lookup B) Extend the DHCP options used for SIP server discovery, to > contain more than only the hostname SIP DHCP can only tell you the hostname of the visited networks outbound service, not your home domains proxy providing SIP outbound service. > B) What seems to be causing this pain in the first place, is the > limitations imposed by current DHCP options. No, not for my requirement (see above). For my requirement, the problem seems to be how to locate the outbound proxy, and determine if it supports STUN on the SIP port, without first having to contact the ordinary SIP servers for my home domain (it.su.se) and send them a REGISTER that results in a 3xx response, or a 2xx response with some Supported: headers or similar. /Fredrik _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 24 04:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FionX-0001sU-Kl; Wed, 24 May 2006 04:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FionW-0001sP-3l for sip@ietf.org; Wed, 24 May 2006 04:32:54 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FionU-0001xi-Nz for sip@ietf.org; Wed, 24 May 2006 04:32:54 -0400 Received: (qmail 2944 invoked by uid 0); 24 May 2006 08:32:50 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 May 2006 08:32:50 -0000 Message-ID: <00a001c67f0c$a5d96220$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Fredrik Thulin" References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> <200605240836.06076.ft@it.su.se> <007c01c67f05$55b46e90$31713b51@BEMBUSTER> <200605241008.30836.ft@it.su.se> Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Wed, 24 May 2006 10:32:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> B) What seems to be causing this pain in the first place, is the >> limitations imposed by current DHCP options. > > No, not for my requirement (see above). For my requirement, the problem > seems to be how to locate the outbound proxy, and determine if it > supports STUN on the SIP port, without first having to contact the > ordinary SIP servers for my home domain (it.su.se) and send them a > REGISTER that results in a 3xx response, or a 2xx response with some > Supported: headers or similar. This to me sounds as if we need something like "callerprefs for outbound proxies / registrars" Something like: REGISTER sip:example.com Accept-Proxy: *;extensions="outbound" 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 May 24 05:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipGn-0004EW-1d; Wed, 24 May 2006 05:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipGl-0004ER-9A for sip@ietf.org; Wed, 24 May 2006 05:03:07 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FipGj-0003IC-UP for sip@ietf.org; Wed, 24 May 2006 05:03:07 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 187321400B2; Wed, 24 May 2006 12:02:58 +0300 (EEST) Received: from rautu (in-vitro222.gprs.dnafinland.fi [62.78.121.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 78DCC1400A6; Wed, 24 May 2006 12:02:47 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 8BC55F01D5; Wed, 24 May 2006 12:02:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17524.8502.26307.674262@rautu.tutpro.com> Date: Wed, 24 May 2006 12:02:46 +0300 From: Juha Heinanen To: "Jeroen van Bemmel" Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? In-Reply-To: <007c01c67f05$55b46e90$31713b51@BEMBUSTER> References: <8B1D53AEF7B03449A6D3771B3B7F850F025610CD@esebe103.NOE.Nokia.com> <200605240836.06076.ft@it.su.se> <007c01c67f05$55b46e90$31713b51@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Jeroen van Bemmel writes: > Consider the following 2 options: > A) Use the hostname / IP discovered through DHCP as a key for DNS lookup > B) Extend the DHCP options used for SIP server discovery, to contain more > than only the hostname DHCP mechanisms are not a replacement of DNS based discovery. discover need to work no matter where i connect my phone to. also, think about residential users behind a simple dsl modem/nat/dhcp server device. it would be difficult to somehow auto-configure it. > B) What seems to be causing this pain in the first place, is the > limitations imposed by current DHCP options. it is not only limitations of options. see above. -- 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 Wed May 24 05:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipQ1-0000PP-Aa; Wed, 24 May 2006 05:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipQ0-0000PK-AP for sip@ietf.org; Wed, 24 May 2006 05:12:40 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FipPy-0003gG-UA for sip@ietf.org; Wed, 24 May 2006 05:12:40 -0400 Received: (qmail 26898 invoked by uid 0); 24 May 2006 09:12:36 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 May 2006 09:12:36 -0000 Message-ID: <00b601c67f12$340b4310$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Hammer \(mhammer\)" , "Cullen Jennings \(fluffy\)" , "IETF SIP List" References: <072C5B76F7CEAB488172C6F64B30B5E3017E6206@xmb-rtp-20b.amer.cisco.com> Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 24 May 2006 11:12:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 >For example, the new mode could require that only redirect servers be >used so that the UAC and UAS (no B2BUAs allowed) be able to establish a >direct signaling connection over TLS. Of course there would be other >details of such an architecture to work out, but at least this would put >a stake in the ground for what is needed to give end-users a true "lock >icon" option. > >Mike This assumes that endpoints have suitable TLS certificates. In practice this would be a problem. What we could do, is turn the current transitive trust model into an end-2-end verifiable trust chain: > > So, how do you KNOW that TLS was actually used at each hop? [...] > > TLS works with HTTP because it works end-to-end, tunneling > through the > > HTTP proxies. If a proxy cheats and acts like a B2BUA for TLS, the > > client can check the cert-name and detect the misbehavior. But with > > sips:, we have no way for the UAC to "check up" on the proxies. > > > > For sips: to give the kind of security assurance you seem > to want, it > > has to work end-to-end "through" the proxies, like https: does. A mechanism could work as follows: UAC inserts a 'Proxy-Require: trust' into its request. This requires that every proxy on the path adds information to its Record-Route header, namely a link to where its certificate can be obtained, and proof that it owns that certificate (e.g. by signing something including its RR-URI and the Call-ID with the private key of the certificate) Both peers can then go and inspect every certificate in the proxy chain, to verify if they trust all proxies ("check up" on them). They still would not KNOW that TLS was used, but based on this established trust they may assume that the proxy will do the right thing 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 May 24 06:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiqB4-0000nA-Gj; Wed, 24 May 2006 06:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiqB3-0000n5-7g for sip@ietf.org; Wed, 24 May 2006 06:01:17 -0400 Received: from [203.200.4.5] (helo=serversmb.kodiaknetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiqB0-0005mN-ON for sip@ietf.org; Wed, 24 May 2006 06:01:17 -0400 Received: from Nataraju ([192.168.3.66]) by serversmb.kodiaknetworks.com (8.11.6/8.11.6) with ESMTP id k4O9vva01333; Wed, 24 May 2006 15:27:57 +0530 From: "Nataraju A B" To: "'Jeroen van Bemmel'" , "'Michael Hammer \(mhammer\)'" , "'Cullen Jennings \(fluffy\)'" , "'IETF SIP List'" Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 24 May 2006 15:27:40 +0530 Message-ID: <001e01c67f18$7ec43b90$4203a8c0@Nataraju> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <00b601c67f12$340b4310$31713b51@BEMBUSTER> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Comments inline... Thanks & Regards, Nataraju A.B. -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Wednesday, May 24, 2006 2:43 PM To: Michael Hammer (mhammer); Cullen Jennings (fluffy); IETF SIP List Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines >For example, the new mode could require that only redirect servers be >used so that the UAC and UAS (no B2BUAs allowed) be able to establish a >direct signaling connection over TLS. Of course there would be other >details of such an architecture to work out, but at least this would put >a stake in the ground for what is needed to give end-users a true "lock >icon" option. > >Mike This assumes that endpoints have suitable TLS certificates. In practice this would be a problem. What we could do, is turn the current transitive trust model into an end-2-end verifiable trust chain: [ABN] how about to have a combination of e2e and hop-by-hop trust model...? > > So, how do you KNOW that TLS was actually used at each hop? [...] [ABN] Any way, every proxy will insert a via header while passing the message downstream, if we mandate every proxy has to insert a some parameter while forwarding a sips request. In this way we can make sure @ the UAS, the request had been forwarded by a trustworthy proxy in between... Does this makes sense... ? > > TLS works with HTTP because it works end-to-end, tunneling > through the > > HTTP proxies. If a proxy cheats and acts like a B2BUA for TLS, the > > client can check the cert-name and detect the misbehavior. But with > > sips:, we have no way for the UAC to "check up" on the proxies. > > > > For sips: to give the kind of security assurance you seem > to want, it > > has to work end-to-end "through" the proxies, like https: does. A mechanism could work as follows: UAC inserts a 'Proxy-Require: trust' into its request. This requires that every proxy on the path adds information to its Record-Route header, namely a link to where its certificate can be obtained, and proof that it owns that certificate (e.g. by signing something including its RR-URI and the Call-ID with the private key of the certificate) Both peers can then go and inspect every certificate in the proxy chain, to verify if they trust all proxies ("check up" on them). They still would not KNOW that TLS was used, but based on this established trust they may assume that the proxy will do the right thing 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 24 09:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitSN-0000qo-AO; Wed, 24 May 2006 09:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitSM-0000qj-5j for sip@ietf.org; Wed, 24 May 2006 09:31:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FitSI-00073b-R7 for sip@ietf.org; Wed, 24 May 2006 09:31:22 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 06:31:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,166,1146466800"; d="scan'208"; a="28804555:sNHT23618876" 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 k4ODVHTL015295; Wed, 24 May 2006 09:31:17 -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.211); Wed, 24 May 2006 09:31:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Date: Wed, 24 May 2006 09:31:16 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6550@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Thread-Index: AcZ+/inTYB004EHhQma5UI1sz4e09wAN7uIA From: "Michael Hammer \(mhammer\)" To: "Jeroen van Bemmel" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 24 May 2006 13:31:17.0554 (UTC) FILETIME=[5610C920:01C67F36] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Huh??? Why are you adding something new into the ACK that wasn't in the original INVITE. Seems like a good way to bugger up the state machine by causing the transaction cleanup to go awry. Why wouldn't the ACK contain the same headers and share the same fate as the INVITE? Please explain. It seems like you should wait for the retry INVITE to add such things. Mike > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Wednesday, May 24, 2006 2:33 AM > To: Paul Kyzivat (pkyzivat) > Cc: sip@ietf.org > Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK >=20 > Paul, >=20 > At the very least, the current table is confusing with=20 > respect to the following text in section 8.2.2.3: "An ACK=20 > request for a 2xx response MUST contain only those Require=20 > and Proxy-Require values that were present in the initial request." >=20 > Although this says "MUST contain *only*" and not "MUST=20 > contain", it seems to suggest that it is at least allowed to=20 > include a Proxy-Require in an ACK to 2xx. >=20 > BTW, now that I notice: also the entry for 'Require'=20 > currently says '-' for ACK >=20 > >I don't see how this makes any sense. Proxy-Require only=20 > makes sense if=20 > >a proxy that doesn't support the option can reject the=20 > request. Since=20 > >ACK gets no response there is no way to reject it. > > > > Paul >=20 > In some cases 'Proxy-Require' is used to request certain=20 > behavior / processing from a proxy. For example in RFC3323,=20 > if "Privacy: header" is added to an ACK, the UA SHOULD add=20 > also a 'Proxy-Require: privacy' to ensure that the target=20 > supports this extension. Although the proxy would not be able=20 > to respond to the ACK, an element not supporting the=20 > extension should probably discard the ACK rather than=20 > forwarding it (without stripping the Via header as required=20 > by the extension in this case). >=20 > I agree that proxy behavior for 'Proxy-Require' in ACK is=20 > different from Proxy-Require in normal requests (again: not=20 > clearly described, I'm speculating that the ACK should be=20 > dropped if not supported here). So either we disallow=20 > Proxy-Require / Require in ACK and update the text in=20 > 8.2.2.3, or we modify table 2/3 and clarify proxy/UAS=20 > behavior for ACK containing these headers >=20 > Regards, >=20 > Jeroen >=20 >=20 > > > > Jeroen van Bemmel wrote: > >> Table 2 in RFC3261 disallows Proxy-Require in ACK requests=20 > (i.e. it=20 > >> has a '-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on=20 > >> the ability to include a Proxy-Require in an ACK to a 2xx=20 > response,=20 > >> although they are not very explicit on this. > >> RFC3261 explicitly says that Proxy-Require MUST NOT be used for=20 > >> CANCEL or ACK to non-2xx (which are hop by hop), but I believe the=20 > >> intention was to allow it for ACK to 2xx. Therefore, table=20 > 2 should=20 > >> say 'o' here Regards, Jeroen > >> > >> > >>=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 May 24 09:49:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fithp-0007Mx-RG; Wed, 24 May 2006 09:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fitho-0007Ms-Hp for sip@ietf.org; Wed, 24 May 2006 09:47:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fithl-0007sx-Ty for sip@ietf.org; Wed, 24 May 2006 09:47:20 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 24 May 2006 06:47:17 -0700 X-IronPort-AV: i="4.05,166,1146466800"; d="scan'208"; a="282112986:sNHT106572096" 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/8.12.11) with ESMTP id k4ODlHla012011; Wed, 24 May 2006 06:47:17 -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 k4ODkxJt015133; Wed, 24 May 2006 06:47:17 -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.211); Wed, 24 May 2006 09:47:06 -0400 Received: from [192.168.1.101] ([10.86.240.167]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 09:47:06 -0400 Message-ID: <447463D9.1080805@cisco.com> Date: Wed, 24 May 2006 09:47:05 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK References: <072C5B76F7CEAB488172C6F64B30B5E3017E6550@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3017E6550@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 13:47:06.0269 (UTC) FILETIME=[8B8B34D0:01C67F38] DKIM-Signature: a=rsa-sha1; q=dns; l=5193; t=1148478437; x=1149342437; c=relaxed/simple; s=sjdkim5001; 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]=20Bug=20in=20RFC3261=3A=20Proxy-Require=20not=20allowed=20 in=20ACK; X=v=3Dcisco.com=3B=20h=3D07UiE8VQe2Ia/tDihGFO+I4sRYA=3D; b=4kt9uwg+Zn3X/1eCX5tB3Bw7qOkGsXZ29ulglUZIHqFc3XIiJWDUFVhtbDDjQRePdn3HTqse fM/a3REo159LZe+Cf3BCaqjE+2sOQ5Nm1HPjxA86qEHLz34QJG7o8GJT; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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't do that - I don't think Jeroen was suggesting it. The reason Require and Proxy-Require are allowed in ACK for 2xx is that there may in fact be extensions for which the ACK can only be processed if that extension is understood. However, since the ACK cannot be rejected, as Paul pointed out, the only Require/Proxy-Require that are permitted in the ACK are a subset of those in the INVITE. The theory is that since this set worked in the INVITE (the request was not rejected), the would be acceptable in the ACK, and thus there would never be a need to reject the ACK. Require/Proxy-Require in those requests are a flag that special treatment is required. Thanks, Jonathan R. Michael Hammer (mhammer) wrote: > Huh??? Why are you adding something new into the ACK that wasn't in the > original INVITE. Seems like a good way to bugger up the state machine > by causing the transaction cleanup to go awry. Why wouldn't the ACK > contain the same headers and share the same fate as the INVITE? Please > explain. It seems like you should wait for the retry INVITE to add such > things. > > Mike > > >>-----Original Message----- >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>Sent: Wednesday, May 24, 2006 2:33 AM >>To: Paul Kyzivat (pkyzivat) >>Cc: sip@ietf.org >>Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK >> >>Paul, >> >>At the very least, the current table is confusing with >>respect to the following text in section 8.2.2.3: "An ACK >>request for a 2xx response MUST contain only those Require >>and Proxy-Require values that were present in the initial request." >> >>Although this says "MUST contain *only*" and not "MUST >>contain", it seems to suggest that it is at least allowed to >>include a Proxy-Require in an ACK to 2xx. >> >>BTW, now that I notice: also the entry for 'Require' >>currently says '-' for ACK >> >> >>>I don't see how this makes any sense. Proxy-Require only >> >>makes sense if >> >>>a proxy that doesn't support the option can reject the >> >>request. Since >> >>>ACK gets no response there is no way to reject it. >>> >>>Paul >> >>In some cases 'Proxy-Require' is used to request certain >>behavior / processing from a proxy. For example in RFC3323, >>if "Privacy: header" is added to an ACK, the UA SHOULD add >>also a 'Proxy-Require: privacy' to ensure that the target >>supports this extension. Although the proxy would not be able >>to respond to the ACK, an element not supporting the >>extension should probably discard the ACK rather than >>forwarding it (without stripping the Via header as required >>by the extension in this case). >> >>I agree that proxy behavior for 'Proxy-Require' in ACK is >>different from Proxy-Require in normal requests (again: not >>clearly described, I'm speculating that the ACK should be >>dropped if not supported here). So either we disallow >>Proxy-Require / Require in ACK and update the text in >>8.2.2.3, or we modify table 2/3 and clarify proxy/UAS >>behavior for ACK containing these headers >> >>Regards, >> >>Jeroen >> >> >> >>>Jeroen van Bemmel wrote: >>> >>>>Table 2 in RFC3261 disallows Proxy-Require in ACK requests >> >>(i.e. it >> >>>>has a '-'). Some standards (e.g. RFC3323, RFC3329) seem to rely on >>>>the ability to include a Proxy-Require in an ACK to a 2xx >> >>response, >> >>>>although they are not very explicit on this. >>>> RFC3261 explicitly says that Proxy-Require MUST NOT be used for >>>>CANCEL or ACK to non-2xx (which are hop by hop), but I believe the >>>>intention was to allow it for ACK to 2xx. Therefore, table >> >>2 should >> >>>>say 'o' here 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 >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP 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 May 24 09:49:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitiU-0007gf-O6; Wed, 24 May 2006 09:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitiT-0007ga-8f for sip@ietf.org; Wed, 24 May 2006 09:48:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FitiR-0007w3-Io for sip@ietf.org; Wed, 24 May 2006 09:48:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 24 May 2006 06:47:40 -0700 X-IronPort-AV: i="4.05,166,1146466800"; d="scan'208"; a="282113275:sNHT3794923896" 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/8.12.11) with ESMTP id k4ODlenT027316; Wed, 24 May 2006 06:47:40 -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 k4ODldJj015507; Wed, 24 May 2006 06:47:39 -0700 (PDT) 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.211); Wed, 24 May 2006 09:47:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on draft-audet-sip-sips-guidelines Date: Wed, 24 May 2006 09:47:38 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E6569@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Comments on draft-audet-sip-sips-guidelines Thread-Index: AcZ/EjXBhxmsfkEPTPCIPW6iqU+jZAAJT8tQ From: "Michael Hammer \(mhammer\)" To: "Jeroen van Bemmel" , "Cullen Jennings \(fluffy\)" , "IETF SIP List" X-OriginalArrivalTime: 24 May 2006 13:47:39.0195 (UTC) FILETIME=[9F2B50B0:01C67F38] DKIM-Signature: a=rsa-sha1; q=dns; l=2936; t=1148478460; x=1149342460; c=relaxed/simple; s=sjdkim8001; 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]=20Comments=20on=20draft-audet-sip-sips-guidelines; X=v=3Dcisco.com=3B=20h=3D7VDHGoYladXKj+9S0wQxlVwEdqI=3D; b=H/3kiZqE7dkRM7hfnQ7R39rYoc6qqvw+WqqlUOrlUoWvqyGrBaorgEkipETCBvv/M8tBPtY5 gD1HjynasCqFWi1O7IY0cKUTEod/kF9Xt9YAGphBA3BQEKmqXdNz4tIp; Authentication-Results: sj-dkim-8.cisco.com; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen, Your solution changes the problem of an endpoint having a suitable TLS certificate to being sure that every proxy on the path has a suitable certificate. If an endpoint doesn't have a certificate, then it is not very robust in supporting real security. The solution you suggest seems to devolve into the solution I suggested as proxies are removed. Adding more players into the chain only weakens security. Reducing middlemen strengthens it. I do like the idea of Proxy-Requiring well specified behavior. I just wonder if the signed object should include both forward and backward pointers to proxies in the chain. Mike > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Wednesday, May 24, 2006 5:13 AM > To: Michael Hammer (mhammer); Cullen Jennings (fluffy); IETF SIP List > Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines >=20 > >For example, the new mode could require that only redirect=20 > servers be=20 > >used so that the UAC and UAS (no B2BUAs allowed) be able to=20 > establish a=20 > >direct signaling connection over TLS. Of course there would=20 > be other=20 > >details of such an architecture to work out, but at least this would=20 > >put a stake in the ground for what is needed to give=20 > end-users a true=20 > >"lock icon" option. > > > >Mike >=20 > This assumes that endpoints have suitable TLS certificates.=20 > In practice this would be a problem. >=20 > What we could do, is turn the current transitive trust model=20 > into an end-2-end verifiable trust chain: >=20 > > > So, how do you KNOW that TLS was actually used at each hop? > [...] > > > TLS works with HTTP because it works end-to-end, tunneling > > through the > > > HTTP proxies. If a proxy cheats and acts like a B2BUA for=20 > TLS, the=20 > > > client can check the cert-name and detect the=20 > misbehavior. But with=20 > > > sips:, we have no way for the UAC to "check up" on the proxies. > > > > > > For sips: to give the kind of security assurance you seem > > to want, it > > > has to work end-to-end "through" the proxies, like https: does. >=20 > A mechanism could work as follows: UAC inserts a=20 > 'Proxy-Require: trust' into its request. This requires that=20 > every proxy on the path adds information to its Record-Route=20 > header, namely a link to where its certificate can be=20 > obtained, and proof that it owns that certificate (e.g. by=20 > signing something including its RR-URI and the Call-ID with=20 > the private key of the > certificate) >=20 > Both peers can then go and inspect every certificate in the=20 > proxy chain, to verify if they trust all proxies ("check up"=20 > on them). They still would not KNOW that TLS was used, but=20 > based on this established trust they may assume that the=20 > proxy will do the right thing >=20 > Regards, >=20 > jeroen >=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 May 24 09:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fitll-0000SW-LK; Wed, 24 May 2006 09:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fitlj-0000Q2-B5 for sip@ietf.org; Wed, 24 May 2006 09:51:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fitlh-00083Y-Ss for sip@ietf.org; Wed, 24 May 2006 09:51:23 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2006 09:51:22 -0400 X-IronPort-AV: i="4.05,166,1146456000"; d="scan'208"; a="89343154:sNHT32203052" 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 k4ODpGvZ007584; Wed, 24 May 2006 09:51:21 -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.211); Wed, 24 May 2006 09:51:16 -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] Bug in RFC3261: Proxy-Require not allowed in ACK Date: Wed, 24 May 2006 09:51:15 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3017E656D@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Thread-Index: AcZ/OIvG5K9jTfDjT76NBqIJwsbdkQAAEGnQ From: "Michael Hammer \(mhammer\)" To: "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 24 May 2006 13:51:16.0935 (UTC) FILETIME=[20F3CD70:01C67F39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 misread it, but my impression was that he was adding something, thus not a subset, thus the potential for the ACK to not reach as far as the INVITE did. Mike > -----Original Message----- > From: Jonathan Rosenberg (jdrosen)=20 > Sent: Wednesday, May 24, 2006 9:47 AM > To: Michael Hammer (mhammer) > Cc: Jeroen van Bemmel; Paul Kyzivat (pkyzivat); sip@ietf.org > Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK >=20 > You can't do that - I don't think Jeroen was suggesting it. >=20 > The reason Require and Proxy-Require are allowed in ACK for=20 > 2xx is that there may in fact be extensions for which the ACK=20 > can only be processed if that extension is understood.=20 > However, since the ACK cannot be rejected, as Paul pointed=20 > out, the only Require/Proxy-Require that are permitted in the=20 > ACK are a subset of those in the INVITE. The theory is that=20 > since this set worked in the INVITE (the request was not=20 > rejected), the would be acceptable in the ACK, and thus there=20 > would never be a need to reject the ACK.=20 > Require/Proxy-Require in those requests are a flag that=20 > special treatment is required. >=20 > Thanks, > Jonathan R. >=20 > Michael Hammer (mhammer) wrote: >=20 > > Huh??? Why are you adding something new into the ACK that=20 > wasn't in the > > original INVITE. Seems like a good way to bugger up the=20 > state machine > > by causing the transaction cleanup to go awry. Why wouldn't the ACK > > contain the same headers and share the same fate as the=20 > INVITE? Please > > explain. It seems like you should wait for the retry=20 > INVITE to add such > > things. > >=20 > > Mike > >=20 > >=20 > >>-----Original Message----- > >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > >>Sent: Wednesday, May 24, 2006 2:33 AM > >>To: Paul Kyzivat (pkyzivat) > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK > >> > >>Paul, > >> > >>At the very least, the current table is confusing with=20 > >>respect to the following text in section 8.2.2.3: "An ACK=20 > >>request for a 2xx response MUST contain only those Require=20 > >>and Proxy-Require values that were present in the initial request." > >> > >>Although this says "MUST contain *only*" and not "MUST=20 > >>contain", it seems to suggest that it is at least allowed to=20 > >>include a Proxy-Require in an ACK to 2xx. > >> > >>BTW, now that I notice: also the entry for 'Require'=20 > >>currently says '-' for ACK > >> > >> > >>>I don't see how this makes any sense. Proxy-Require only=20 > >> > >>makes sense if=20 > >> > >>>a proxy that doesn't support the option can reject the=20 > >> > >>request. Since=20 > >> > >>>ACK gets no response there is no way to reject it. > >>> > >>>Paul > >> > >>In some cases 'Proxy-Require' is used to request certain=20 > >>behavior / processing from a proxy. For example in RFC3323,=20 > >>if "Privacy: header" is added to an ACK, the UA SHOULD add=20 > >>also a 'Proxy-Require: privacy' to ensure that the target=20 > >>supports this extension. Although the proxy would not be able=20 > >>to respond to the ACK, an element not supporting the=20 > >>extension should probably discard the ACK rather than=20 > >>forwarding it (without stripping the Via header as required=20 > >>by the extension in this case). > >> > >>I agree that proxy behavior for 'Proxy-Require' in ACK is=20 > >>different from Proxy-Require in normal requests (again: not=20 > >>clearly described, I'm speculating that the ACK should be=20 > >>dropped if not supported here). So either we disallow=20 > >>Proxy-Require / Require in ACK and update the text in=20 > >>8.2.2.3, or we modify table 2/3 and clarify proxy/UAS=20 > >>behavior for ACK containing these headers > >> > >>Regards, > >> > >>Jeroen > >> > >> > >> > >>>Jeroen van Bemmel wrote: > >>> > >>>>Table 2 in RFC3261 disallows Proxy-Require in ACK requests=20 > >> > >>(i.e. it=20 > >> > >>>>has a '-'). Some standards (e.g. RFC3323, RFC3329) seem=20 > to rely on=20 > >>>>the ability to include a Proxy-Require in an ACK to a 2xx=20 > >> > >>response,=20 > >> > >>>>although they are not very explicit on this. > >>>> RFC3261 explicitly says that Proxy-Require MUST NOT be used for=20 > >>>>CANCEL or ACK to non-2xx (which are hop by hop), but I=20 > believe the=20 > >>>>intention was to allow it for ACK to 2xx. Therefore, table=20 > >> > >>2 should=20 > >> > >>>>say 'o' here Regards, Jeroen > >>>> > >>>> > >>>> > >> > >>------------------------------------------------------------ > --------- > >> > >>>>--- > >>>> > >>>>_______________________________________________ > >>>>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=20 > >>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 >=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 May 24 09:57:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitpU-0001Yy-Kj; Wed, 24 May 2006 09:55:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitpT-0001Yj-EN for sip@ietf.org; Wed, 24 May 2006 09:55:15 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FitpR-0008Jh-Pl for sip@ietf.org; Wed, 24 May 2006 09:55:15 -0400 Received: (qmail 3025 invoked by uid 0); 24 May 2006 13:55:11 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 24 May 2006 13:55:11 -0000 Message-ID: <00ff01c67f39$ada87680$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Michael Hammer \(mhammer\)" , "Jonathan Rosenberg \(jdrosen\)" References: <072C5B76F7CEAB488172C6F64B30B5E3017E656D@xmb-rtp-20b.amer.cisco.com> Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Date: Wed, 24 May 2006 15:55:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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, Yes, obviously the same "Proxy-Require: privacy" and "Privacy: header" would need to be present in the INVITE. For this to work properly, any proxy that accepts a Proxy-Require in an INVITE MUST Record-Route, else the ACK would end up some place else and the scenario you describe would occur. For example, RFC3329 could be more explicit on this (section 4.1 message 4). I believe an update was being worked on? Regards, Jeroen ----- Original Message ----- From: "Michael Hammer (mhammer)" To: "Jonathan Rosenberg (jdrosen)" Cc: "Jeroen van Bemmel" ; "Paul Kyzivat (pkyzivat)" ; Sent: Wednesday, May 24, 2006 3:51 PM Subject: RE: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Maybe I misread it, but my impression was that he was adding something, thus not a subset, thus the potential for the ACK to not reach as far as the INVITE did. Mike > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Wednesday, May 24, 2006 9:47 AM > To: Michael Hammer (mhammer) > Cc: Jeroen van Bemmel; Paul Kyzivat (pkyzivat); sip@ietf.org > Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK > > You can't do that - I don't think Jeroen was suggesting it. > > The reason Require and Proxy-Require are allowed in ACK for > 2xx is that there may in fact be extensions for which the ACK > can only be processed if that extension is understood. > However, since the ACK cannot be rejected, as Paul pointed > out, the only Require/Proxy-Require that are permitted in the > ACK are a subset of those in the INVITE. The theory is that > since this set worked in the INVITE (the request was not > rejected), the would be acceptable in the ACK, and thus there > would never be a need to reject the ACK. > Require/Proxy-Require in those requests are a flag that > special treatment is required. > > Thanks, > Jonathan R. > > Michael Hammer (mhammer) wrote: > > > Huh??? Why are you adding something new into the ACK that > wasn't in the > > original INVITE. Seems like a good way to bugger up the > state machine > > by causing the transaction cleanup to go awry. Why wouldn't the ACK > > contain the same headers and share the same fate as the > INVITE? Please > > explain. It seems like you should wait for the retry > INVITE to add such > > things. > > > > Mike > > > > > >>-----Original Message----- > >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >>Sent: Wednesday, May 24, 2006 2:33 AM > >>To: Paul Kyzivat (pkyzivat) > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK > >> > >>Paul, > >> > >>At the very least, the current table is confusing with > >>respect to the following text in section 8.2.2.3: "An ACK > >>request for a 2xx response MUST contain only those Require > >>and Proxy-Require values that were present in the initial request." > >> > >>Although this says "MUST contain *only*" and not "MUST > >>contain", it seems to suggest that it is at least allowed to > >>include a Proxy-Require in an ACK to 2xx. > >> > >>BTW, now that I notice: also the entry for 'Require' > >>currently says '-' for ACK > >> > >> > >>>I don't see how this makes any sense. Proxy-Require only > >> > >>makes sense if > >> > >>>a proxy that doesn't support the option can reject the > >> > >>request. Since > >> > >>>ACK gets no response there is no way to reject it. > >>> > >>>Paul > >> > >>In some cases 'Proxy-Require' is used to request certain > >>behavior / processing from a proxy. For example in RFC3323, > >>if "Privacy: header" is added to an ACK, the UA SHOULD add > >>also a 'Proxy-Require: privacy' to ensure that the target > >>supports this extension. Although the proxy would not be able > >>to respond to the ACK, an element not supporting the > >>extension should probably discard the ACK rather than > >>forwarding it (without stripping the Via header as required > >>by the extension in this case). > >> > >>I agree that proxy behavior for 'Proxy-Require' in ACK is > >>different from Proxy-Require in normal requests (again: not > >>clearly described, I'm speculating that the ACK should be > >>dropped if not supported here). So either we disallow > >>Proxy-Require / Require in ACK and update the text in > >>8.2.2.3, or we modify table 2/3 and clarify proxy/UAS > >>behavior for ACK containing these headers > >> > >>Regards, > >> > >>Jeroen > >> > >> > >> > >>>Jeroen van Bemmel wrote: > >>> > >>>>Table 2 in RFC3261 disallows Proxy-Require in ACK requests > >> > >>(i.e. it > >> > >>>>has a '-'). Some standards (e.g. RFC3323, RFC3329) seem > to rely on > >>>>the ability to include a Proxy-Require in an ACK to a 2xx > >> > >>response, > >> > >>>>although they are not very explicit on this. > >>>> RFC3261 explicitly says that Proxy-Require MUST NOT be used for > >>>>CANCEL or ACK to non-2xx (which are hop by hop), but I > believe the > >>>>intention was to allow it for ACK to 2xx. Therefore, table > >> > >>2 should > >> > >>>>say 'o' here 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 > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use > >>sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP 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 May 24 13:58:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixZa-0006mx-Ss; Wed, 24 May 2006 13:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixZZ-0006ms-Bl for sip@ietf.org; Wed, 24 May 2006 13:55:05 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FixZX-0004d3-1p for sip@ietf.org; Wed, 24 May 2006 13:55:05 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 827606C01D for ; Wed, 24 May 2006 13:54:58 -0400 (EDT) Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips From: "Dale R. Worley" To: Sip In-Reply-To: <17522.45483.589133.702489@rautu.tutpro.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> Content-Type: text/plain Date: Wed, 24 May 2006 13:54:58 -0400 Message-Id: <1148493298.3423.4.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Tue, 2006-05-23 at 09:54 +0300, Juha Heinanen wrote: > this discussion has clearly revealed that meaning of sips uri scheme is > not well defined in rfc3261 and that there exist wide confusion and > conflicting opinions about it. Possibly the only certain fact about sips! > as i mentioned earlier, sips was added to rfc3261 at the very last > minute, which clearly was a mistake. sip working group must have guts > to admit it and act accordingly. > > since there is no indication that an easy fix could exist, i therefore > propose deprecating sips uri scheme until it is well defined and can be > reintroduced. this would be a big benefit to sip implementors. That sounds like a good idea to me. But can we retract that feature from the market at this point? 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 May 24 14:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixkY-00049Q-Vs; Wed, 24 May 2006 14:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FixkX-00049A-PV for sip@ietf.org; Wed, 24 May 2006 14:06:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FixkW-00058c-H4 for sip@ietf.org; Wed, 24 May 2006 14:06:25 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2006 14:06:19 -0400 X-IronPort-AV: i="4.05,167,1146456000"; d="scan'208"; a="89373914:sNHT957406140" 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 k4OI6JvF009595; Wed, 24 May 2006 14:06:19 -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.211); Wed, 24 May 2006 14:06:19 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 14:06:18 -0400 Message-ID: <4474A09A.5030305@cisco.com> Date: Wed, 24 May 2006 14:06:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> In-Reply-To: <1148493298.3423.4.camel@niagra.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 18:06:18.0816 (UTC) FILETIME=[C1958C00:01C67F5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Dale R. Worley wrote: > On Tue, 2006-05-23 at 09:54 +0300, Juha Heinanen wrote: >> as i mentioned earlier, sips was added to rfc3261 at the very last >> minute, which clearly was a mistake. sip working group must have guts >> to admit it and act accordingly. >> >> since there is no indication that an easy fix could exist, i therefore >> propose deprecating sips uri scheme until it is well defined and can be >> reintroduced. this would be a big benefit to sip implementors. I proposed the same thing earlier in the thread. But after further discussion I think that is at least premature. I think there is still a possibility of keeping it and providing an adequate definition. (In other words, keep the name and replace everything else.) But I think we are not yet close to an understanding of what an adequate definition would be. > That sounds like a good idea to me. But can we retract that feature > from the market at this point? I'm far from sure what feature it is that we would be retracting. At best I imagine there are a bunch of distinct and non-interoperable features using the same scheme. 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 May 24 14:44:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyJY-0003mw-Hs; Wed, 24 May 2006 14:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyJW-0003mo-Vr for sip@ietf.org; Wed, 24 May 2006 14:42:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiyJS-0007S1-5f for sip@ietf.org; Wed, 24 May 2006 14:42:34 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 24 May 2006 11:42:30 -0700 X-IronPort-AV: i="4.05,168,1146466800"; d="scan'208"; a="1812169756:sNHT86884570" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4OIgTmX002253; Wed, 24 May 2006 11:42:29 -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 k4OIgTsF028620; Wed, 24 May 2006 11:42:29 -0700 (PDT) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 11:42:29 -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] Bug in RFC3261: Proxy-Require not allowed in ACK Date: Wed, 24 May 2006 11:37:20 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB901D53@xmb-sjc-21e.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK thread-index: AcZ/Odw/paNZc0ZbQKa4/aBEjbTxTAAJZ+RQ From: "Arunachalam Venkatraman \(arunvenk\)" To: "Jeroen van Bemmel" , "Michael Hammer \(mhammer\)" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 24 May 2006 18:42:29.0161 (UTC) FILETIME=[CF35E990:01C67F61] DKIM-Signature: a=rsa-sha1; q=dns; l=7537; t=1148496149; x=1149360149; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=arunvenk@cisco.com; z=From:=22Arunachalam=20Venkatraman=20\(arunvenk\)=22=20 |Subject:RE=3A=20[Sip]=20Bug=20in=20RFC3261=3A=20Proxy-Require=20not=20allowed=20 in=20ACK; X=v=3Dcisco.com=3B=20h=3D3eebQe1ncWm+ZsCIJ7oRMDr9QqU=3D; b=rqq10XUJsRtt6jeJmSW5YFyFwHv+xYjUo1GIO3SJYpj8IHXOzG23pY1c9NvJdtSv+gygcNWS ytG0LoeHb9gcWfZh16cHdy5fMDQ58DBEIfw147jwcs8TuV37aqUd3KOp; Authentication-Results: sj-dkim-4.cisco.com; header.From=arunvenk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: sip@ietf.org, "Paul Kyzivat \(pkyzivat\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 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 if the Contact in the 2xx caused routing through a new proxy to the UAS? This could occur even if the proxies record-routed. The Proxy_Require may not be acceptable to this new proxy.=20 -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Wednesday, May 24, 2006 8:55 AM To: Michael Hammer (mhammer); Jonathan Rosenberg (jdrosen) Cc: sip@ietf.org; Paul Kyzivat (pkyzivat) Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Mike, Yes, obviously the same "Proxy-Require: privacy" and "Privacy: header" would need to be present in the INVITE. For this to work properly, any proxy that accepts a Proxy-Require in an INVITE MUST Record-Route, else the ACK would end up some place else and the scenario you describe would occur. For example, RFC3329 could be more explicit on this (section 4.1 message 4).=20 I believe an update was being worked on? Regards, Jeroen ----- Original Message ----- From: "Michael Hammer (mhammer)" To: "Jonathan Rosenberg (jdrosen)" Cc: "Jeroen van Bemmel" ; "Paul Kyzivat (pkyzivat)"=20 ; Sent: Wednesday, May 24, 2006 3:51 PM Subject: RE: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK Maybe I misread it, but my impression was that he was adding something, thus not a subset, thus the potential for the ACK to not reach as far as the INVITE did. Mike > -----Original Message----- > From: Jonathan Rosenberg (jdrosen) > Sent: Wednesday, May 24, 2006 9:47 AM > To: Michael Hammer (mhammer) > Cc: Jeroen van Bemmel; Paul Kyzivat (pkyzivat); sip@ietf.org > Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK > > You can't do that - I don't think Jeroen was suggesting it. > > The reason Require and Proxy-Require are allowed in ACK for > 2xx is that there may in fact be extensions for which the ACK > can only be processed if that extension is understood. > However, since the ACK cannot be rejected, as Paul pointed > out, the only Require/Proxy-Require that are permitted in the > ACK are a subset of those in the INVITE. The theory is that > since this set worked in the INVITE (the request was not > rejected), the would be acceptable in the ACK, and thus there > would never be a need to reject the ACK. > Require/Proxy-Require in those requests are a flag that > special treatment is required. > > Thanks, > Jonathan R. > > Michael Hammer (mhammer) wrote: > > > Huh??? Why are you adding something new into the ACK that > wasn't in the > > original INVITE. Seems like a good way to bugger up the > state machine > > by causing the transaction cleanup to go awry. Why wouldn't the ACK > > contain the same headers and share the same fate as the > INVITE? Please > > explain. It seems like you should wait for the retry > INVITE to add such > > things. > > > > Mike > > > > > >>-----Original Message----- > >>From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >>Sent: Wednesday, May 24, 2006 2:33 AM > >>To: Paul Kyzivat (pkyzivat) > >>Cc: sip@ietf.org > >>Subject: Re: [Sip] Bug in RFC3261: Proxy-Require not allowed in ACK > >> > >>Paul, > >> > >>At the very least, the current table is confusing with > >>respect to the following text in section 8.2.2.3: "An ACK > >>request for a 2xx response MUST contain only those Require > >>and Proxy-Require values that were present in the initial request." > >> > >>Although this says "MUST contain *only*" and not "MUST > >>contain", it seems to suggest that it is at least allowed to > >>include a Proxy-Require in an ACK to 2xx. > >> > >>BTW, now that I notice: also the entry for 'Require' > >>currently says '-' for ACK > >> > >> > >>>I don't see how this makes any sense. Proxy-Require only > >> > >>makes sense if > >> > >>>a proxy that doesn't support the option can reject the > >> > >>request. Since > >> > >>>ACK gets no response there is no way to reject it. > >>> > >>>Paul > >> > >>In some cases 'Proxy-Require' is used to request certain > >>behavior / processing from a proxy. For example in RFC3323, > >>if "Privacy: header" is added to an ACK, the UA SHOULD add > >>also a 'Proxy-Require: privacy' to ensure that the target > >>supports this extension. Although the proxy would not be able > >>to respond to the ACK, an element not supporting the > >>extension should probably discard the ACK rather than > >>forwarding it (without stripping the Via header as required > >>by the extension in this case). > >> > >>I agree that proxy behavior for 'Proxy-Require' in ACK is > >>different from Proxy-Require in normal requests (again: not > >>clearly described, I'm speculating that the ACK should be > >>dropped if not supported here). So either we disallow > >>Proxy-Require / Require in ACK and update the text in > >>8.2.2.3, or we modify table 2/3 and clarify proxy/UAS > >>behavior for ACK containing these headers > >> > >>Regards, > >> > >>Jeroen > >> > >> > >> > >>>Jeroen van Bemmel wrote: > >>> > >>>>Table 2 in RFC3261 disallows Proxy-Require in ACK requests > >> > >>(i.e. it > >> > >>>>has a '-'). Some standards (e.g. RFC3323, RFC3329) seem > to rely on > >>>>the ability to include a Proxy-Require in an ACK to a 2xx > >> > >>response, > >> > >>>>although they are not very explicit on this. > >>>> RFC3261 explicitly says that Proxy-Require MUST NOT be used for > >>>>CANCEL or ACK to non-2xx (which are hop by hop), but I > believe the > >>>>intention was to allow it for ACK to 2xx. Therefore, table > >> > >>2 should > >> > >>>>say 'o' here 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 > >> > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use > >>sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 24 14:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyXL-0000xi-Gk; Wed, 24 May 2006 14:56:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiyXK-0000xF-0i for sip@ietf.org; Wed, 24 May 2006 14:56:50 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiyXI-0008Ag-Ms for sip@ietf.org; Wed, 24 May 2006 14:56:49 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4OIulip009758; Wed, 24 May 2006 13:56:47 -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 k4OIuku22684; Wed, 24 May 2006 13:56:46 -0500 (CDT) Message-ID: <4474AC6E.4000902@lucent.com> Date: Wed, 24 May 2006 13:56:46 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> In-Reply-To: <4474A09A.5030305@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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: , Content-Type: multipart/mixed; boundary="===============1388771694==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1388771694== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070806050800020506010803" This is a cryptographically signed message in MIME format. --------------ms070806050800020506010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I'm far from sure what feature it is that we would be retracting. At > best I imagine there are a bunch of distinct and non-interoperable > features using the same scheme. At the last SIP bakeoff, there were 73 distinct SIP implementations, out of which 30 supported TLS. As per the notes on TLS implementation from the bakeoff, Robert wrote that: There was significant testing of TLS and SRTP. TLS interoperability is solidifying. So, at the very least SIP entities are increasingly supporting TLS. Whether or not they do the right thing -- whatever that may be -- in the context of a sips scheme is a different thing. The discussion to date appears to indicate that there exists problems, the most severe of which appears to be the end-to-end security semantics versus the hop-by-hop. 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) --------------ms070806050800020506010803 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjQxODU2NDZaMCMGCSqGSIb3DQEJ BDEWBBT+c3HMvFJO3qElpu0Sy7pt0rJ94zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAaT0VXfBhCrjd5T9zjwtpSubq+tSATGOnH0BcCiPsEpoMs4c5xCdg pfIjFUC8j56XL6J3hTMVkHv7yNk6x6w2wZ7QzlML7OLlKENfAeqky8Du2UIQMTMfkHsz2ha0 pTGi0JisxC7XCsCWfOKNjTkZJifXv7cCQhDbQmEdwFMIQBEAAAAAAAA= --------------ms070806050800020506010803-- --===============1388771694== 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 --===============1388771694==-- From sip-bounces@ietf.org Wed May 24 16:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fizzm-0004RW-A8; Wed, 24 May 2006 16:30:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fizzk-0004Qs-K3 for sip@ietf.org; Wed, 24 May 2006 16:30:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fizzi-00068M-5k for sip@ietf.org; Wed, 24 May 2006 16:30:16 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 13:30:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,169,1146466800"; d="scan'208"; a="28853660:sNHT22134688" 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 k4OKUDTL026941; Wed, 24 May 2006 16:30:13 -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.211); Wed, 24 May 2006 16:30:13 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 16:30:13 -0400 Message-ID: <4474C254.5070407@cisco.com> Date: Wed, 24 May 2006 16:30:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> In-Reply-To: <4474AC6E.4000902@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 20:30:13.0238 (UTC) FILETIME=[DC19C960:01C67F70] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 wasn't talking about problems with TLS. It is the "sips" semantics that are so ambiguous that I am doubtful we can even consider it a common feature. That was the point of Francois' work, which has served to expose how much difference of opinion there is. *Anything* we do to firm up SIPS is likely to break *all* the existing implementations of SIPS. Paul Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> I'm far from sure what feature it is that we would be retracting. At >> best I imagine there are a bunch of distinct and non-interoperable >> features using the same scheme. > > At the last SIP bakeoff, there were 73 distinct SIP implementations, > out of which 30 supported TLS. As per the notes on TLS > implementation from the bakeoff, Robert wrote that: > > There was significant testing of TLS and SRTP. TLS > interoperability is solidifying. > > So, at the very least SIP entities are increasingly supporting > TLS. Whether or not they do the right thing -- whatever that may > be -- in the context of a sips scheme is a different thing. > The discussion to date appears to indicate that there exists > problems, the most severe of which appears to be the end-to-end > security semantics versus the hop-by-hop. > > Thanks. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 24 17:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0v4-0000cT-3H; Wed, 24 May 2006 17:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0v2-0000cO-Ih for sip@ietf.org; Wed, 24 May 2006 17:29:28 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0v1-0002Ab-9o for sip@ietf.org; Wed, 24 May 2006 17:29:28 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4OLTIo2012888; Wed, 24 May 2006 16:29:18 -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 k4OLTHu17062; Wed, 24 May 2006 16:29:17 -0500 (CDT) Message-ID: <4474D02D.3020200@lucent.com> Date: Wed, 24 May 2006 16:29:17 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <4474C254.5070407@cisco.com> In-Reply-To: <4474C254.5070407@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Paul Kyzivat wrote: > I wasn't talking about problems with TLS. It is the "sips" semantics > that are so ambiguous that I am doubtful we can even consider it a > common feature. That was the point of Francois' work, which has > served to expose how much difference of opinion there is. *Anything* > we do to firm up SIPS is likely to break *all* the existing > implementations of SIPS. Francois' work has indicated an ambiguity in sips, yes. But I don't think it's all downhill. There are security properties that folks are looking from sips that simply won't happen. These are things like magically showing a locked icon on a sips URI, or sending sdescriptions end-to-end in a secure manner, or mandating that all hops -- even the last hop -- be secured through TLS. But there are other problems that may be solveable. For instance, requiring proxies to redirect instead of recurse on being presented with a sip URI when they started with a sips URI, solidifying use of sips as an AoR, solving the mess of registrations mentioned in Section 4 of Francois' draft, try to close the upgrading gaps in Section 26.4.4 where an intermediary upgrades a sip URI to a sips URI, thereby giving an illusion to the UAS that TLS was used from beginning to end (the UAS could look at the Via headers to figure that out, for instance), maybe abolishing upgrading and downgrading completely, and so on And finally, implementers put TLS to support sips; thus when I see that the number of TLS implementations are increasing at the bakeoffs, and that TLS interoperability is solidifying, that means to me that at least some aspects of sips are well understood by the implementation community to solidify this interoperability. They could be as simple as ensuring that all hops used TLS on seeing a sips URI as the next hop URI. It's the corner cases that we should pay attention to and provide guidance on, or deprecate. Not the sips scheme itself. Thanks, - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 24 18:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1uc-0005Aq-U5; Wed, 24 May 2006 18:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj1ua-0005Al-SO for sip@ietf.org; Wed, 24 May 2006 18:33:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj1uY-00062C-Is for sip@ietf.org; Wed, 24 May 2006 18:33:04 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 May 2006 15:33:02 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,169,1146466800"; d="scan'208"; a="28864372:sNHT25361784" 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 k4OMX1vF007604; Wed, 24 May 2006 18:33:01 -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.211); Wed, 24 May 2006 18:33:01 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 18:33:01 -0400 Message-ID: <4474DF1D.2000405@cisco.com> Date: Wed, 24 May 2006 18:33:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <4474C254.5070407@cisco.com> <4474D02D.3020200@lucent.com> In-Reply-To: <4474D02D.3020200@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 22:33:01.0473 (UTC) FILETIME=[03E93910:01C67F82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> I wasn't talking about problems with TLS. It is the "sips" semantics >> that are so ambiguous that I am doubtful we can even consider it a >> common feature. That was the point of Francois' work, which has >> served to expose how much difference of opinion there is. *Anything* >> we do to firm up SIPS is likely to break *all* the existing >> implementations of SIPS. > > Francois' work has indicated an ambiguity in sips, yes. But I > don't think it's all downhill. There are security properties that > folks are looking from sips that simply won't happen. These > are things like magically showing a locked icon on a sips URI, > or sending sdescriptions end-to-end in a secure manner, or > mandating that all hops -- even the last hop -- be secured through > TLS. > > But there are other problems that may be solveable. ... Yeah, maybe it will be possible to get to the point where, if none of the hops is lying, then it is known that all hops use TLS. And maybe that means you know with some certainty that you are connected to something that elements you (transitively) trust claim is authorized to act on behalf of the address you called. But that is pretty much useless unless you can also be certain the media is connected to that same place. Is that kind of connection sufficient to exchange SRTP media keys via sdescriptions, and then be confident that your media is securely and privately connected to whatever the target wants it to be connected to? (Again assuming that you trust all the intermediate hops to honor your wishes.) *If* that is the case, then maybe it is worth doing and worthy of bestowing that lock icon. If that isn't the case, then I fail to see the point of doing it at all. Paul > For instance, > requiring proxies to redirect instead of recurse on being > presented with a sip URI when they started with a sips URI, > solidifying use of sips as an AoR, solving the mess of > registrations mentioned in Section 4 of Francois' draft, try to > close the upgrading gaps in Section 26.4.4 where an intermediary > upgrades a sip URI to a sips URI, thereby giving an illusion to > the UAS that TLS was used from beginning to end (the UAS could > look at the Via headers to figure that out, for instance), > maybe abolishing upgrading and downgrading completely, and > so on > > And finally, implementers put TLS to support sips; thus when I > see that the number of TLS implementations are increasing at > the bakeoffs, and that TLS interoperability is solidifying, > that means to me that at least some aspects of sips are > well understood by the implementation community to solidify > this interoperability. They could be as simple as ensuring > that all hops used TLS on seeing a sips URI as the next > hop URI. It's the corner cases that we should pay attention to > and provide guidance on, or deprecate. Not the sips scheme > itself. > > Thanks, > > - vijay > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 24 18:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2HR-0007sU-0i; Wed, 24 May 2006 18:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2HO-0007sP-Kz for sip@ietf.org; Wed, 24 May 2006 18:56:38 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj2HI-0007as-Hw for sip@ietf.org; Wed, 24 May 2006 18:56:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4OMuObf000283; Wed, 24 May 2006 17:56:24 -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 k4OMuNu20288; Wed, 24 May 2006 17:56:23 -0500 (CDT) Message-ID: <4474E497.1090301@lucent.com> Date: Wed, 24 May 2006 17:56: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: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <4474C254.5070407@cisco.com> <4474D02D.3020200@lucent.com> <4474DF1D.2000405@cisco.com> In-Reply-To: <4474DF1D.2000405@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae 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: , Content-Type: multipart/mixed; boundary="===============1737634709==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1737634709== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030607070502040104070509" This is a cryptographically signed message in MIME format. --------------ms030607070502040104070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Yeah, maybe it will be possible to get to the point where, if none of > the hops is lying, then it is known that all hops use TLS. And maybe > that means you know with some certainty that you are connected to > something that elements you (transitively) trust claim is authorized to > act on behalf of the address you called. [...] > *If* that is the case, then maybe it is worth doing and worthy of > bestowing that lock icon. If that isn't the case, then I fail to see the > point of doing it at all. We should not claim that sips is capable of locking the icon. We should not claim that sips is capable of solving the prisoner's dilemma problem; it is not. It is not capable of an end-to-end security model. It will not work in an adverserial network where no one trusts anyone else. Correct me if I am wrong, but we did not design SIP to work in a completely adverserial network. We trust our proxies to "do the right thing" -- be that forking to multiple endpoints or doing a transport conversion, or interfacing to the right location server, or simply proxying our requests in a sane manner. But, assuming that we get beyond this blocking point, much as we bestow trust in our proxies to do the right thing, I don't see the harm in using sips in a hop-by-hop security model *as long as we enunciate what the drawbacks are*. What has been missing thus far has been the notion of where does sips and TLS help and where they don't. The last set of drafts coming out on this subject has, at the very least, shed some light on this. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms030607070502040104070509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjQyMjU2MjNaMCMGCSqGSIb3DQEJ BDEWBBRV2fXVIrflku8spdAbAR366FfsgDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAZnpmKPKApnnbzuFsnvEzrItWXsZEsfbYSsdUXt+nDWgMX2MAgtT+ w4muz8tyvMeuFMDDl8vRVLyGAxzRJiz2UVo13kao9RznhV9QTD2NCMslmUmXUkEzENT4NXPX 8Vm7NjNDY4WECwd8NC38m9cXtMDlv2L7bReP6WtFhX6V8XIAAAAAAAA= --------------ms030607070502040104070509-- --===============1737634709== 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 --===============1737634709==-- From sip-bounces@ietf.org Wed May 24 19:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2r1-00014d-Fp; Wed, 24 May 2006 19:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2r0-00014V-64 for sip@ietf.org; Wed, 24 May 2006 19:33:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj2qy-0001LS-SQ for sip@ietf.org; Wed, 24 May 2006 19:33:26 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2006 19:33:24 -0400 X-IronPort-AV: i="4.05,169,1146456000"; d="scan'208"; a="89404041:sNHT33863436" 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 k4ONXOTL002503; Wed, 24 May 2006 19:33:24 -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.211); Wed, 24 May 2006 19:33:24 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 May 2006 19:33:23 -0400 Message-ID: <4474ED43.9060508@cisco.com> Date: Wed, 24 May 2006 19:33:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <4474C254.5070407@cisco.com> <4474D02D.3020200@lucent.com> <4474DF1D.2000405@cisco.com> <4474E497.1090301@lucent.com> In-Reply-To: <4474E497.1090301@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2006 23:33:24.0004 (UTC) FILETIME=[731B9640:01C67F8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> Yeah, maybe it will be possible to get to the point where, if none of >> the hops is lying, then it is known that all hops use TLS. And maybe >> that means you know with some certainty that you are connected to >> something that elements you (transitively) trust claim is authorized >> to act on behalf of the address you called. > [...] >> *If* that is the case, then maybe it is worth doing and worthy of >> bestowing that lock icon. If that isn't the case, then I fail to see >> the point of doing it at all. > > We should not claim that sips is capable of locking the icon. We > should not claim that sips is capable of solving the prisoner's > dilemma problem; it is not. It is not capable of an end-to-end > security model. It will not work in an adverserial network > where no one trusts anyone else. I think we may be on almost the same page. I agree that trust in the proxies is reasonable in many environments. I suspect I am more willing than you are to bestow the lock icon in such a situation. > Correct me if I am wrong, but we did not design SIP to > work in a completely adverserial network. We trust our proxies to > "do the right thing" -- be that forking to multiple endpoints > or doing a transport conversion, or interfacing to the right > location server, or simply proxying our requests in a sane > manner. > > But, assuming that we get beyond this blocking point, much > as we bestow trust in our proxies to do the right thing, I > don't see the harm in using sips in a hop-by-hop security > model *as long as we enunciate what the drawbacks are*. I agree. But here I go a little further. It must be possible to boil this down into something (e.g. the lock icon) that can be communicated to the end user, and understood. If the system sometimes establishes calls with SIPS, and other times with SIP, there is no benefit unless there is a perceptible difference to the user. If the user gets no benefit from SIPS, then why bother with it. I can only see a few benefits to the user that are worth the trouble: - a guarantee that they are talking to the intended target - a guarantee that nobody other than the other party in the call has access to the media. (Well, maybe we also have to also allow the network operator(s), their agents, and government agencies access.) I would be inclined to use the lock icon when both of the above hold. I'm not sure there is enough value in telling the user about the first if the second doesn't hold to confuse the issue by having two levels of security. The downside of course is that if you start telling users they sometimes get these benefits then they will ask why they don't *always* get them. > What > has been missing thus far has been the notion of where > does sips and TLS help and where they don't. The last set > of drafts coming out on this subject has, at the very least, > shed some light on this. The meaning of the security indicator does need to be clearly explained to users. If it is, and if the property it provides is indeed a valuable one, then it will be worthwhile. Having a well defined meaning for SIPS is also important, if it is a stepping stone to the bigger goal. If a meaning is chosen that doesn't help provide something helpful to the user then we might as well not bother. 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 May 24 20:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3Xa-0002LU-A2; Wed, 24 May 2006 20:17:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3XY-0002Js-Mo for sip@ietf.org; Wed, 24 May 2006 20:17:24 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj3XX-0003eF-EI for sip@ietf.org; Wed, 24 May 2006 20:17:24 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4P0HL0P019568; Wed, 24 May 2006 19:17:22 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 25 May 2006 01:17:21 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB012F2A57B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Martin.Hynar@tietoenator.com'" , "'sip@ietf.org'" Subject: RE: [Sip] Status of content indirection mechanism draft Date: Thu, 25 May 2006 01:17:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 It is currently in AUTH48 and we are just awaiting one author to confirm OK. He is being chased (particularly as the publication of another RFC is being held up by this one). Expect end of the month at the moment. Note that one a document is is the editor's queue, it cannot by definition expire. It is still in the drafts folder, and you can ignore the date on the cover page. The editor's queue can be viewed here http://www.rfc-editor.org/queue.html regards Keith > -----Original Message----- > From: Martin.Hynar@tietoenator.com > [mailto:Martin.Hynar@tietoenator.com] > Sent: 24 May 2006 08:28 > To: sip@ietf.org > Subject: [Sip] Status of content indirection mechanism draft > > > Hi all, > > I've one simple question regarding status of > draft-ietf-sip-content-indirect-mech-05. It has expired a year ago and > it is still in rfc editor queue. Is there planned some action > with that > draft (rfc release)? > > br, Martin > > Martin Hynar > Software Specialist > > TietoEnator > Czech Software Center > Phone: +420 599 096 022 > E-mail: Martin.Hynar@TietoEnator.com > > Vystavni 292/13 > CZ-709 16 Ostrava > > www.tietoenator.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 May 24 20:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3wH-00016O-27; Wed, 24 May 2006 20:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj3wF-00016I-Di for sip@ietf.org; Wed, 24 May 2006 20:42:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj3Ib-0002v0-UD for sip@ietf.org; Wed, 24 May 2006 20:01:57 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fj32P-00011A-4z for sip@ietf.org; Wed, 24 May 2006 19:45:19 -0400 Received: by nf-out-0910.google.com with SMTP id c29so169690nfb for ; Wed, 24 May 2006 16:45:11 -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=knbNN8rOAB6hgxJ8Ktt5hlQ/Ud03KzYiVAcXmhXgMQbOiTqxiNweKOr3AEl6vQL3QKVxfc03uCeWpAUuj8F0/5GAEY/ke6+OGjjpMNPuqrrCjPIqjWRJrJKsmDJYSF+E2f+gHIF6Y3WuB0VbxgKnXHpBE4JhKxX/C4mFhVbYzFw= Received: by 10.49.94.19 with SMTP id w19mr1874073nfl; Wed, 24 May 2006 16:45:09 -0700 (PDT) Received: by 10.48.80.11 with HTTP; Wed, 24 May 2006 16:45:09 -0700 (PDT) Message-ID: <4ff4e7370605241645s5018563fgaf4dcbd7fd6bfb8e@mail.gmail.com> Date: Wed, 24 May 2006 16:45:09 -0700 From: Venkatesh To: jdrosen@cisco.com, sip@ietf.org MIME-Version: 1.0 X-Spam-Score: -2.5 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [Sip] Resolution on reusing payload types and RFC 3264. X-BeenThere: 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="===============0988722995==" Errors-To: sip-bounces@ietf.org --===============0988722995== Content-Type: multipart/alternative; boundary="----=_Part_68367_10691820.1148514309308" ------=_Part_68367_10691820.1148514309308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Re-sending this email. Any pointers to this will be appreciated. Thanks Venkatesh On 5/17/06, Venkatesh wrote: > > Hi: > > Per section 8.3.2 of RFC 3264, dynamic payload types are fixed for a > session and MUST NOT change for the duration of the session. This > requirement leads to problems when you have B2BUA's in the picture. I was > looking at bugzilla and I found the issues with this requirement outlined= in > http://bugs.sipit.net/show_bug.cgi?id=3D739. The bug goes on to say the = fix > should be to relax this requirement. I wanted to know if there was any fi= nal > agreement on the same and if yes, what the final resolution was? Any > pointers will be helpful. > > Thanks > Venkatesh > ------=_Part_68367_10691820.1148514309308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Re-sending this email. Any pointers to this will be appreciated.
 
Thanks
Venkatesh

 
On 5/17/06, = Venkatesh <vvenkatar@gmail.co= m> wrote:
Hi:
 
Per section 8.3.2 of RFC 3264, dynamic payload types are fixed for a s= ession and MUST NOT change for the duration of the session. This requiremen= t leads to problems when you have B2BUA's in the picture. I was looking at = bugzilla and I found the issues with this requirement outlined in=20 http://bugs.sipit.n= et/show_bug.cgi?id=3D739.  The bug goes on to say the fix should b= e to relax this requirement. I wanted to know if there was any final agreem= ent on the same and if yes, what the final resolution was? Any pointers wil= l be helpful.=20
 
Thanks
Venkatesh

------=_Part_68367_10691820.1148514309308-- --===============0988722995== 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 --===============0988722995==-- From sip-bounces@ietf.org Wed May 24 21:07:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4I3-0006qw-NO; Wed, 24 May 2006 21:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj4I1-0006qr-Q4 for sip@ietf.org; Wed, 24 May 2006 21:05:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj4I0-0007eH-Gl for sip@ietf.org; Wed, 24 May 2006 21:05: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 k4P10G023340; Wed, 24 May 2006 21:00:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 24 May 2006 20:05:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF09EC9E4C@zrc2hxm0.corp.nortel.com> In-Reply-To: <4474E497.1090301@lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ/hh4BiAEr8kfFTruW95zwryG9BQAENRTQ From: "Francois Audet" To: "Vijay K. Gurbani" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 agree with what Vijay is saying. Deprecating sips will do no good. We just need to explain what sips means (and doesn't mean). And, yes, it does NOT mean a reliable lock icon. If we need a lock icon, that's something different. > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com]=20 > Sent: Wednesday, May 24, 2006 15:56 > To: Paul Kyzivat > Cc: Sip > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 > Paul Kyzivat wrote: > > Yeah, maybe it will be possible to get to the point where,=20 > if none of > > the hops is lying, then it is known that all hops use TLS.=20 > And maybe=20 > > that means you know with some certainty that you are connected to=20 > > something that elements you (transitively) trust claim is=20 > authorized to=20 > > act on behalf of the address you called. > [...] > > *If* that is the case, then maybe it is worth doing and worthy of > > bestowing that lock icon. If that isn't the case, then I=20 > fail to see the=20 > > point of doing it at all. >=20 > We should not claim that sips is capable of locking the icon.=20 > We should not claim that sips is capable of solving the=20 > prisoner's dilemma problem; it is not. It is not capable of=20 > an end-to-end security model. It will not work in an=20 > adverserial network where no one trusts anyone else. >=20 > Correct me if I am wrong, but we did not design SIP to > work in a completely adverserial network. We trust our=20 > proxies to "do the right thing" -- be that forking to=20 > multiple endpoints or doing a transport conversion, or=20 > interfacing to the right location server, or simply proxying=20 > our requests in a sane manner. >=20 > But, assuming that we get beyond this blocking point, much > as we bestow trust in our proxies to do the right thing, I=20 > don't see the harm in using sips in a hop-by-hop security=20 > model *as long as we enunciate what the drawbacks are*. What=20 > has been missing thus far has been the notion of where does=20 > sips and TLS help and where they don't. The last set of=20 > drafts coming out on this subject has, at the very least,=20 > shed some light on this. >=20 > - vijay > --=20 > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Bell Laboratories, Lucent Technologies, Inc. > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 25 01:42:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj8Zg-0003Z9-6k; Thu, 25 May 2006 01:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj8Ze-0003Z3-I8 for sip@ietf.org; Thu, 25 May 2006 01:39:54 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj8Zb-0008Ul-6G for sip@ietf.org; Thu, 25 May 2006 01:39:54 -0400 Received: by tutpro.com (Postfix, from userid 65534) id E4BA91400AC; Thu, 25 May 2006 08:39:49 +0300 (EEST) Received: from rautu (in-vitro158.gprs.dnafinland.fi [62.78.121.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D652A13F981; Thu, 25 May 2006 08:39:43 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 6E9A2F01D5; Thu, 25 May 2006 08:39:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17525.17186.384537.223811@rautu.tutpro.com> Date: Thu, 25 May 2006 08:39:46 +0300 From: Juha Heinanen To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <4474AC6E.4000902@lucent.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Vijay K. Gurbani writes: > There was significant testing of TLS and SRTP. TLS > interoperability is solidifying. > > So, at the very least SIP entities are increasingly supporting > TLS. Whether or not they do the right thing -- whatever that may > be -- in the context of a sips scheme is a different thing. transport=tls is fine. it is sips that nobody knows what it means. -- 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 May 25 10:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGMq-00065H-B9; Thu, 25 May 2006 09:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGMo-00064s-OQ for sip@ietf.org; Thu, 25 May 2006 09:59:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGMn-0003b4-Eg for sip@ietf.org; Thu, 25 May 2006 09:59:10 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2006 09:59:09 -0400 X-IronPort-AV: i="4.05,172,1146456000"; d="scan'208"; a="89446861:sNHT32141244" 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 k4PDx9TL018881; Thu, 25 May 2006 09:59:09 -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.211); Thu, 25 May 2006 09:59:08 -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-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 25 May 2006 09:59:08 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcZ/hh4BiAEr8kfFTruW95zwryG9BQAENRTQABsNW2A= From: "Michael Hammer \(mhammer\)" To: "Francois Audet" , "Vijay K. Gurbani" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 25 May 2006 13:59:08.0864 (UTC) FILETIME=[64A83400:01C68003] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Maybe put the lock in a bunny's mouth to show that it is only hop-by-hop. The "lock icon" to be meaningful should be consistent. =20 HTTPS has already set the standard for what this means. Mike > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Wednesday, May 24, 2006 9:05 PM > To: Vijay K. Gurbani; Paul Kyzivat (pkyzivat) > Cc: Sip > Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 > I agree with what Vijay is saying. >=20 > Deprecating sips will do no good. >=20 > We just need to explain what sips means (and doesn't mean). >=20 > And, yes, it does NOT mean a reliable lock icon. If we need a=20 > lock icon, that's something different. >=20 >=20 > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > Sent: Wednesday, May 24, 2006 15:56 > > To: Paul Kyzivat > > Cc: Sip > > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips > >=20 > >=20 > > Paul Kyzivat wrote: > > > Yeah, maybe it will be possible to get to the point where, > > if none of > > > the hops is lying, then it is known that all hops use TLS.=20 > > And maybe > > > that means you know with some certainty that you are connected to=20 > > > something that elements you (transitively) trust claim is > > authorized to > > > act on behalf of the address you called. > > [...] > > > *If* that is the case, then maybe it is worth doing and worthy of=20 > > > bestowing that lock icon. If that isn't the case, then I > > fail to see the > > > point of doing it at all. > >=20 > > We should not claim that sips is capable of locking the icon.=20 > > We should not claim that sips is capable of solving the prisoner's=20 > > dilemma problem; it is not. It is not capable of an end-to-end=20 > > security model. It will not work in an adverserial network=20 > where no=20 > > one trusts anyone else. > >=20 > > Correct me if I am wrong, but we did not design SIP to work in a=20 > > completely adverserial network. We trust our proxies to=20 > "do the right=20 > > thing" -- be that forking to multiple endpoints or doing a=20 > transport=20 > > conversion, or interfacing to the right location server, or simply=20 > > proxying our requests in a sane manner. > >=20 > > But, assuming that we get beyond this blocking point, much as we=20 > > bestow trust in our proxies to do the right thing, I don't see the=20 > > harm in using sips in a hop-by-hop security model *as long as we=20 > > enunciate what the drawbacks are*. What has been missing=20 > thus far has=20 > > been the notion of where does sips and TLS help and where=20 > they don't. =20 > > The last set of drafts coming out on this subject has, at the very=20 > > least, shed some light on this. > >=20 > > - vijay > > -- > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > Bell Laboratories, Lucent Technologies, Inc. > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 25 10:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjH3t-0004t4-8P; Thu, 25 May 2006 10:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjH3r-0004sz-Jk for sip@ietf.org; Thu, 25 May 2006 10:43:39 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjH3o-0007Tg-9u for sip@ietf.org; Thu, 25 May 2006 10:43:39 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4PEhXib008005; Thu, 25 May 2006 09:43:33 -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 k4PEhXw24315; Thu, 25 May 2006 09:43:33 -0500 (CDT) Message-ID: <4475C295.6000605@lucent.com> Date: Thu, 25 May 2006 09:43:33 -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: "Michael Hammer (mhammer)" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 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: , Content-Type: multipart/mixed; boundary="===============1936076956==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1936076956== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020400090507070200060801" This is a cryptographically signed message in MIME format. --------------ms020400090507070200060801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Hammer (mhammer) wrote: > Maybe put the lock in a bunny's mouth to show that it is only > hop-by-hop. I like that! It's very descriptive and intuitive. Maybe we can use the Energizer bunny ;-) > The "lock icon" to be meaningful should be consistent. > HTTPS has already set the standard for what this means. Agreed, but then SIP is not HTTP. The way we use proxies in SIP and the nature of services they provide is different -- but you already know that. Maybe we ought to have a new scheme, sipss (for strong security) that will have the same semantics as https does across a chain of proxies; namely once the destination is reached, the transport is upgraded and certs/keys/ciphers are exchanged/negotiated end to end. That way, sips suffices for h-b-h security, and those requiring e2e security can use the sipss scheme. 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) --------------ms020400090507070200060801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjUxNDQzMzNaMCMGCSqGSIb3DQEJ BDEWBBRTQnhQqde4epqTlr23Vwyb567X+TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAI4SwjzwWmzUshbBERMpRwyPXni1aCJVR0GJvE0tmGnN1JGuEEE23 e7mni2q9IcjJEMWoarS4X02UPaysLcRvfbWAQ00/0cmX9ahSwVSJo5zlevcSDOvNG/Evcl8n 5Yctrc6U6BkLyAAQh8JtpI81AKPTDvasAj7s0zcRaDai2rwAAAAAAAA= --------------ms020400090507070200060801-- --===============1936076956== 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 --===============1936076956==-- From sip-bounces@ietf.org Thu May 25 11:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIAw-0000L5-Tg; Thu, 25 May 2006 11:55:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIAu-0000Ky-QB for sip@ietf.org; Thu, 25 May 2006 11:55:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIAt-00053i-Fo for sip@ietf.org; Thu, 25 May 2006 11:55:00 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 May 2006 08:54:59 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="28924269:sNHT23987360" 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 k4PFswTL019200; Thu, 25 May 2006 11:54: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.211); Thu, 25 May 2006 11:54:58 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 11:54:58 -0400 Message-ID: <4475D352.7010802@cisco.com> Date: Thu, 25 May 2006 11:54:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2006 15:54:58.0453 (UTC) FILETIME=[92EF5450:01C68013] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Sip , Francois Audet , "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 I don't care what the indicator is. But it needs to be some indicator that is clear. Paul Michael Hammer (mhammer) wrote: > Maybe put the lock in a bunny's mouth to show that it is only > hop-by-hop. > > The "lock icon" to be meaningful should be consistent. > HTTPS has already set the standard for what this means. > > Mike > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Wednesday, May 24, 2006 9:05 PM >> To: Vijay K. Gurbani; Paul Kyzivat (pkyzivat) >> Cc: Sip >> Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >> >> I agree with what Vijay is saying. >> >> Deprecating sips will do no good. >> >> We just need to explain what sips means (and doesn't mean). >> >> And, yes, it does NOT mean a reliable lock icon. If we need a >> lock icon, that's something different. >> >> >>> -----Original Message----- >>> From: Vijay K. Gurbani [mailto:vkg@lucent.com] >>> Sent: Wednesday, May 24, 2006 15:56 >>> To: Paul Kyzivat >>> Cc: Sip >>> Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips >>> >>> >>> Paul Kyzivat wrote: >>>> Yeah, maybe it will be possible to get to the point where, >>> if none of >>>> the hops is lying, then it is known that all hops use TLS. >>> And maybe >>>> that means you know with some certainty that you are connected to >>>> something that elements you (transitively) trust claim is >>> authorized to >>>> act on behalf of the address you called. >>> [...] >>>> *If* that is the case, then maybe it is worth doing and worthy of >>>> bestowing that lock icon. If that isn't the case, then I >>> fail to see the >>>> point of doing it at all. >>> We should not claim that sips is capable of locking the icon. >>> We should not claim that sips is capable of solving the prisoner's >>> dilemma problem; it is not. It is not capable of an end-to-end >>> security model. It will not work in an adverserial network >> where no >>> one trusts anyone else. >>> >>> Correct me if I am wrong, but we did not design SIP to work in a >>> completely adverserial network. We trust our proxies to >> "do the right >>> thing" -- be that forking to multiple endpoints or doing a >> transport >>> conversion, or interfacing to the right location server, or simply >>> proxying our requests in a sane manner. >>> >>> But, assuming that we get beyond this blocking point, much as we >>> bestow trust in our proxies to do the right thing, I don't see the >>> harm in using sips in a hop-by-hop security model *as long as we >>> enunciate what the drawbacks are*. What has been missing >> thus far has >>> been the notion of where does sips and TLS help and where >> they don't. >>> The last set of drafts coming out on this subject has, at the very >>> least, shed some light on this. >>> >>> - vijay >>> -- >>> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >>> Bell Laboratories, Lucent Technologies, Inc. >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 25 15:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjL6v-0005Mb-7R; Thu, 25 May 2006 15:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjL6t-0005MW-Fu for sip@ietf.org; Thu, 25 May 2006 15:03:03 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjL6s-0004iz-7y for sip@ietf.org; Thu, 25 May 2006 15:03:03 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4PJ3019022394; Thu, 25 May 2006 14:03:00 -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 k4PJ30w25178; Thu, 25 May 2006 14:03:00 -0500 (CDT) Message-ID: <4475FF64.4070403@lucent.com> Date: Thu, 25 May 2006 14:03:00 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> In-Reply-To: <17525.17186.384537.223811@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: 93238566e09e6e262849b4f805833007 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 Juha Heinanen wrote: > Vijay K. Gurbani writes: > > > There was significant testing of TLS and SRTP. TLS > > interoperability is solidifying. > > > > So, at the very least SIP entities are increasingly supporting > > TLS. Whether or not they do the right thing -- whatever that may > > be -- in the context of a sips scheme is a different thing. > > transport=tls is fine. it is sips that nobody knows what it means. transport=tls was fine in the days when TCP was the only transport over which TLS could be used. It's use now would be ambigious, given DTLS -- which I note just became RFC4347 last mont -- and the potential of using TLS over SCTP. I would think that transport=tls, if we were to resurrect it and make it legal ABNF, would cause more ambiguity. Which transport did we mean -- TLS over TCP? UDP? SCTP? ...? Thanks. - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 25 15:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLH0-0008Qu-T6; Thu, 25 May 2006 15:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLGz-0008Qp-7C for sip@ietf.org; Thu, 25 May 2006 15:13:29 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLGx-0005nL-SF for sip@ietf.org; Thu, 25 May 2006 15:13:29 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 8E76A1400A4; Thu, 25 May 2006 22:13:26 +0300 (EEST) Received: from rautu (guanine82.gprs.dnafinland.fi [62.78.120.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id C744E140018; Thu, 25 May 2006 22:13:18 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 207C6F03C1; Thu, 25 May 2006 22:13:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17526.463.76553.396380@rautu.tutpro.com> Date: Thu, 25 May 2006 22:13:19 +0300 From: Juha Heinanen To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <4475FF64.4070403@lucent.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Vijay K. Gurbani writes: > transport=tls was fine in the days when TCP was the only transport > over which TLS could be used. It's use now would be ambigious, > given DTLS -- which I note just became RFC4347 last mont -- and > the potential of using TLS over SCTP. > > I would think that transport=tls, if we were to resurrect it and > make it legal ABNF, would cause more ambiguity. Which transport > did we mean -- TLS over TCP? UDP? SCTP? ...? if tls is not good, invent another name for tls/tcp or tls/sctp. my point is that SIPS uri scheme is useless, but there is value in tls transport over tcp. -- 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 May 25 15:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLnr-0003Cx-2X; Thu, 25 May 2006 15:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLnp-0003Cs-G4 for sip@ietf.org; Thu, 25 May 2006 15:47:25 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLno-0007up-7t for sip@ietf.org; Thu, 25 May 2006 15:47:25 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4PJlEtV028464; Thu, 25 May 2006 14:47:16 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k4PJlEw07471; Thu, 25 May 2006 14:47:14 -0500 (CDT) Message-ID: <447609C2.40109@lucent.com> Date: Thu, 25 May 2006 14:47:14 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> In-Reply-To: <17526.463.76553.396380@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: de4f315c9369b71d7dd5909b42224370 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > if tls is not good, invent another name for tls/tcp or tls/sctp. my > point is that SIPS uri scheme is useless, I guess that's where the disconnect is. I, and at least Francois and maybe Jonathan don't see it as entirely useless. It probably has no purchase in an end-to-end security model (displaying a bunny- less padlock), but assuming we iron the kinks out, it plays within our hop by hop trust model. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 25 15:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqg-0005Nr-MU; Thu, 25 May 2006 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjLqU-0005Io-0g for sip@ietf.org; Thu, 25 May 2006 15:50:10 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjLqR-00089y-KP for sip@ietf.org; Thu, 25 May 2006 15:50:09 -0400 Received: from [192.168.1.5] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4PJpIt9027237 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 25 May 2006 14:51:20 -0500 In-Reply-To: <4475C295.6000605@lucent.com> References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Thu, 25 May 2006 14:50:03 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 May 25, 2006, at 9:43 AM, Vijay K. Gurbani wrote: > Michael Hammer (mhammer) wrote: >> Maybe put the lock in a bunny's mouth to show that it is only >> hop-by-hop. > > I like that! It's very descriptive and intuitive. Maybe we > can use the Energizer bunny ;-) Yes, like this thread. It just keeps on going! > >> The "lock icon" to be meaningful should be consistent. HTTPS has >> already set the standard for what this means. > > Agreed, but then SIP is not HTTP. The way we use proxies > in SIP and the nature of services they provide is different -- > but you already know that. > > Maybe we ought to have a new scheme, sipss (for strong security) > that will have the same semantics as https does across a chain > of proxies; namely once the destination is reached, the transport > is upgraded and certs/keys/ciphers are exchanged/negotiated > end to end. > > That way, sips suffices for h-b-h security, and those requiring > e2e security can use the sipss scheme. I kind of like this. SIPSS: should either use a pass-through-TLS (ala HTTP) or redirect-only model, require media encryption, two-way certification, and a few other things. How about an ID proposing the requirements and the "what the user gets out of a lock icon" 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 Thu May 25 17:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMyf-0004BA-3L; Thu, 25 May 2006 17:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjMyd-0004B5-RQ for sip@ietf.org; Thu, 25 May 2006 17:02:39 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjMyc-0007jr-JT for sip@ietf.org; Thu, 25 May 2006 17:02:39 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4PL2bDi013471; Thu, 25 May 2006 16:02:37 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k4PL2bw22391; Thu, 25 May 2006 16:02:37 -0500 (CDT) Message-ID: <44761B6C.9090500@lucent.com> Date: Thu, 25 May 2006 16:02:36 -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] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> In-Reply-To: <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > I kind of like this. SIPSS: should either use a pass-through-TLS (ala > HTTP) or redirect-only model, require media encryption, two-way > certification, and a few other things. How about an ID proposing the > requirements and the "what the user gets out of a lock icon" discussion? OK. I will get one out before Montreal. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 25 17:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNAe-00069b-Ru; Thu, 25 May 2006 17:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjNAd-00069R-29 for sip@ietf.org; Thu, 25 May 2006 17:15:03 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjNAY-0008OC-En for sip@ietf.org; Thu, 25 May 2006 17:15:03 -0400 Received: (qmail 14464 invoked by uid 0); 25 May 2006 21:14:45 -0000 Received: from unknown (HELO webmail.zonnet.nl) ([10.170.1.95]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 25 May 2006 21:14:45 -0000 Received: by webmail.zonnet.nl (Postfix, from userid 33) id F0FA48BC; Thu, 25 May 2006 23:14:48 +0200 (CEST) Received: from 81.59.178.113 ( [81.59.178.113]) as user jbemmel@localhost by webmail.versatel.nl with HTTP; Thu, 25 May 2006 23:14:48 +0200 Message-ID: <1148591688.44761e48e2a5f@webmail.versatel.nl> Date: Thu, 25 May 2006 23:14:48 +0200 From: jbemmel@zonnet.nl To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> <44761B6C.9090500@lucent.com> In-Reply-To: <44761B6C.9090500@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 81.59.178.113 X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Better to use a different name, e.g. SIPSEC SIPSS looks like SIPS misspelled. That´s a bad start for something intended to be secure : too easy for a user to make a typo Regards, jeroen Citeren "Vijay K. Gurbani" : > Dean Willis wrote: > > I kind of like this. SIPSS: should either use a pass-through-TLS (ala > > HTTP) or redirect-only model, require media encryption, two-way > > certification, and a few other things. How about an ID proposing the > > requirements and the "what the user gets out of a lock icon" discussion? > > OK. I will get one out before Montreal. > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 25 18:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjOax-0004qZ-DH; Thu, 25 May 2006 18:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjOau-0004gd-Of for sip@ietf.org; Thu, 25 May 2006 18:46:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjOas-00017y-CJ for sip@ietf.org; Thu, 25 May 2006 18:46:16 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 25 May 2006 15:46:14 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="1813038491:sNHT33463956" 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/8.12.11) with ESMTP id k4PMkDdw026418; Thu, 25 May 2006 15:46:13 -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 k4PMkCJj004845; Thu, 25 May 2006 15:46:12 -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.211); Thu, 25 May 2006 18:46:12 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 18:46:12 -0400 Message-ID: <447633B3.60307@cisco.com> Date: Thu, 25 May 2006 18:46:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: jbemmel@zonnet.nl Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> <44761B6C.9090500@lucent.com> <1148591688.44761e48e2a5f@webmail.versatel.nl> In-Reply-To: <1148591688.44761e48e2a5f@webmail.versatel.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 May 2006 22:46:12.0099 (UTC) FILETIME=[0592ED30:01C6804D] DKIM-Signature: a=rsa-sha1; q=dns; l=2445; t=1148597173; x=1149461173; c=relaxed/simple; s=sjdkim5001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DqMZkKJm39M0lEr45GIc7ahrWa2w=3D; b=1mzQ1VIfJYbAAVXjc0v2X+MD/iaxxYomHwuTtMZ3hTfWV3IpKkzdMLg9VsmxwOBf7yAUMsku Qod1aVVbPFOhTSCS+M6uf4ZdvqGTVKor9kM0niDWD7HKP0JhqoVfjsXS; 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: Sip , "Vijay K. Gurbani" , 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 jbemmel@zonnet.nl wrote: > Better to use a different name, e.g. SIPSEC > > SIPSS looks like SIPS misspelled. That´s a bad start for something intended to be secure : too easy for a user > to make a typo While I agree in part, I don't think it is likely that many people will be making secure phone calls by typing in SIPSS or SIPSEC URIs. Most people don't type in HTTPS URIs either. Most of those are the result of link following. I imagine secure phoning will be the same, or via some sort of "secure" option button on a phone. In my practical experience, a web "session" is usually started using HTTP, and then transitions to HTTPS later. I suppose something similar might be possible with SIP: you could start a call with SIP and exchange indications that SIPS is supported. Then one side could REFER/Replaces the other side to a SIPS/SIPSS/SIPSEC URI that allows a secure session. I think we are badly in need of the use cases, so we can ensure that we have a mechanism that supports them, rather than inventing a mechanism that supports nothing useful. Paul > Regards, > > jeroen > > Citeren "Vijay K. Gurbani" : > >> Dean Willis wrote: >>> I kind of like this. SIPSS: should either use a pass-through-TLS (ala >>> HTTP) or redirect-only model, require media encryption, two-way >>> certification, and a few other things. How about an ID proposing the >>> requirements and the "what the user gets out of a lock icon" discussion? >> OK. I will get one out before Montreal. >> >> 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 >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 25 23:44:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTDL-0000VP-4k; Thu, 25 May 2006 23:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTDK-0000VK-3Y for sip@ietf.org; Thu, 25 May 2006 23:42:14 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjTDI-0001eB-Oe for sip@ietf.org; Thu, 25 May 2006 23:42:14 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4Q3g8JV004864; Thu, 25 May 2006 22:42:08 -0500 (CDT) Received: from [135.255.29.225] (chrism.lra.lucent.com [135.255.29.225]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k4Q3g7w26469; Thu, 25 May 2006 22:42:07 -0500 (CDT) Message-ID: <44767910.60303@lucent.com> Date: Thu, 25 May 2006 22:42:08 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> <44761B6C.9090500@lucent.com> <1148591688.44761e48e2a5f@webmail.versatel.nl> <447633B3.60307@cisco.com> In-Reply-To: <447633B3.60307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Paul Kyzivat wrote: > While I agree in part, I don't think it is likely that many people will > be making secure phone calls by typing in SIPSS or SIPSEC URIs. Most > people don't type in HTTPS URIs either. Most of those are the result of > link following. I think your mileage may vary. I think what you say would have been true a year or so ago. However, given that the media has scared the public crazy about Internet security, chances are fairly good that the average person not associated with the IETF knows the difference between a http and a https URI. They may not know what goes underneath the hood when they specify a https URI, but they have come to associate https with trust that they bestow when commencing on e-commerce and banking and travel reservations, and getting their yearly credit report free online, and what have you. Thanks, - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 06:20:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZO3-0000E7-1Z; Fri, 26 May 2006 06:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZO1-0000E2-5M for sip@ietf.org; Fri, 26 May 2006 06:17:41 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjZNz-00057i-OQ for sip@ietf.org; Fri, 26 May 2006 06:17:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4QAHcDC028582; Fri, 26 May 2006 13:17:38 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:17:35 +0300 Received: from [172.21.35.178] ([172.21.35.178]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 May 2006 13:17:34 +0300 Message-ID: <4476D578.8080608@nokia.com> Date: Fri, 26 May 2006 13:16:24 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "ext Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> In-Reply-To: <447609C2.40109@lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 10:17:34.0948 (UTC) FILETIME=[9B475A40:01C680AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Sip , 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 ext Vijay K. Gurbani wrote: > Juha Heinanen wrote: >> if tls is not good, invent another name for tls/tcp or tls/sctp. my >> point is that SIPS uri scheme is useless, > > I guess that's where the disconnect is. I, and at least Francois > and maybe Jonathan don't see it as entirely useless. It probably > has no purchase in an end-to-end security model (displaying a bunny- > less padlock), but assuming we iron the kinks out, it plays within > our hop by hop trust model. Can you elaborate what use case you have that requires/benefits from SIPS, then? 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 Fri May 26 06:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZWk-00063o-PR; Fri, 26 May 2006 06:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZWj-00063L-IA for sip@ietf.org; Fri, 26 May 2006 06:26:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjZWj-00061U-G9 for sip@ietf.org; Fri, 26 May 2006 06:26:41 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjZVN-00055H-PS for sip@ietf.org; Fri, 26 May 2006 06:25:18 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4QAPE8H001467; Fri, 26 May 2006 13:25:15 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:25:14 +0300 Received: from [172.21.35.178] ([172.21.35.178]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 May 2006 13:25:14 +0300 Message-ID: <4476D74D.9000104@nokia.com> Date: Fri, 26 May 2006 13:24:13 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <4474C254.5070407@cisco.com> <4474D02D.3020200@lucent.com> <4474DF1D.2000405@cisco.com> <4474E497.1090301@lucent.com> <4474ED43.9060508@cisco.com> In-Reply-To: <4474ED43.9060508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 10:25:14.0692 (UTC) FILETIME=[AD4EB840:01C680AE] X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Sip , "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 ext Paul Kyzivat wrote: > I can only see a few benefits to the user that are worth the trouble: > > - a guarantee that they are talking to the intended target > - a guarantee that nobody other than the other party in the call > has access to the media. (Well, maybe we also have to also > allow the network operator(s), their agents, and government > agencies access.) Agree 100%. > I would be inclined to use the lock icon when both of the above hold. > I'm not sure there is enough value in telling the user about the first > if the second doesn't hold to confuse the issue by having two levels of > security. Agree. > The downside of course is that if you start telling users they sometimes > get these benefits then they will ask why they don't *always* get them. Right. This is why I personally don't see the value in a different URI scheme at all. If the user is given a choice to call bob@example.com securely or insecurely, it's a no-brainer, and the sip URI scheme will sink into oblivion eventually. Maybe there's some value in an indication as a means to aid in protecting against bid-down, but I'm not sure exactly how that would work either. >> What >> has been missing thus far has been the notion of where >> does sips and TLS help and where they don't. The last set >> of drafts coming out on this subject has, at the very least, >> shed some light on this. > > The meaning of the security indicator does need to be clearly explained > to users. If it is, and if the property it provides is indeed a valuable > one, then it will be worthwhile. > > Having a well defined meaning for SIPS is also important, if it is a > stepping stone to the bigger goal. If a meaning is chosen that doesn't > help provide something helpful to the user then we might as well not > bother. I'm again in violent agreement here. 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 Fri May 26 06:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZaL-0007wH-2W; Fri, 26 May 2006 06:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjZaK-0007wC-D9 for sip@ietf.org; Fri, 26 May 2006 06:30:24 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjZaJ-0006s1-LB for sip@ietf.org; Fri, 26 May 2006 06:30:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4QAUMxU004226; Fri, 26 May 2006 13:30:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:30:22 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 13:30:21 +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] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Fri, 26 May 2006 13:30:20 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> In-Reply-To: <007c01c67f05$55b46e90$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Thread-Index: AcZ/BWZzqRQxUoV4SlekVGO68ooXNwBoRwLA From: To: , X-OriginalArrivalTime: 26 May 2006 10:30:21.0750 (UTC) FILETIME=[64540D60:01C680AF] X-Spam-Score: 0.2 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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, What comes to the approach to use DNS for automatically discovering the proxies supporting SIP Outbound: >One thing to note here is that current clients in general=20 >don't have a way to lookup or prefer proxies with specific features.=20 I would challenge this by claiming that before draft-ietf-sip-outbound the clients did not have any strong reason to do so. But my opinion=20 is that the strong reason has emerged with SIP Outbound, which is essential to enable the UA to traverse NAT to use any feature of SIP. >My suggestion for TXT was rooted in the expectation that we'll=20 >soon find ourselves with a need for discovery of other features too. > Maybe it isn't so unreasonable to define new values for NAPTR service, > since the old ones are for SIP and the new ones are for SIP+STUN+more > service? If it is, then perhaps the idea with DNS based provisioning of > outbound SIP service isn't a good idea after all... In my understanding SIP Outbound (with its additional STUN support multiplexed to SIP port) is such a major discontinuity point, that will not happen every day. From RFC 3261 onwards in my opinion there is no other SIP extension that would be as essential for the UAs. So to traverse NATs, the UA would simply need to find a proxy to=20 support SIP Outbound, rather than to opt using any proxy it finds=20 but to restrain itself to use features defined in draft-ietf-sip-outbound. Does anyone have a different opinion on this basic assumption ? --- Revisiting the requirements we have for SIP Outbound autodiscovery, unfortunately I do not think either of Jeroen's solutions A) or B) would be the right way to go. Argument against B) was already given by Fredrik and Juha: it is not only about resolving the domain name returned by the DHCP (for a visited network) but also finding the outbound proxy (of the home network) supporting SIP Outbound, by a UA that=20 is only configured with the AOR of the user. The proxy should=20 be found based on the hostname within the AOR, nothing to do with DHCP in that case, even if the solution must also cover the DHCP based proxy discovery, too. Argument against A) is that different servers should be selected when the very same domain name (domain of the AOR of a user) is resolved for two different purposes: 1 When the user tries to find an outbound proxy (supporting SIP Outbound for NAT traversal) based on his/her own AOR: should result those servers the service provider would like his own clients to use as outbound proxies (with STUN keepalive support). -> The UA when trying to register and set up a flow would perform a specific discovery for servers supporting SIP Outbound 2 When clients of other service providers try to reach the user and are resolving the AOR of the user: should result those servers the service provider would like external users to use=20 when contacting the domain (no need for STUN keepalive support). -> The UA or proxy trying to access a domain would perform a conventional RFC 3263 processing for the AOR and find the corresponding servers (possibly not supporting SIP Outb) I can not see how in the NAPTR H2U rewrite solution we would get two different results (proxy farms) for resolving the same=20 AOR. If the aim would be to use the NAPTR H2U only for case 1 (registration based on the AOR), I would find it strange to require to use those rewrites only to indicate servers with SIP Outbound support, in any other way than to do it with a name hack (e.g. to resolve the name as "ob.example.com" etc.). Also I think even this recent suggestion is not aligned with=20 the expectations that I and Fredrik have for the solution: > This to me sounds as if we need something like "callerprefs for outbound=20 > proxies / registrars" > > Something like: > > REGISTER sip:example.com > Accept-Proxy: *;extensions=3D"outbound" This would not prevent the UA to blindly try to register via several proxies, to check if any of them would support SIP Outbound, rather than discovering those having the support needed, as part of resolving the URI. Or like Fredrik has put it: > No, not for my requirement (see above). For my requirement, the problem > seems to be how to locate the outbound proxy, and determine if it > supports STUN on the SIP port, WITHOUT FIRST having to contact the > ordinary SIP servers for my home domain (it.su.se) and send them a > REGISTER that results in a 3xx response, or a 2xx response with some > Supported: headers or similar. So as a conclusion, for a feasible solution point of view, we still only have the NAPTR "SIP-O" and TXT records proposed and no clear concensus of which one to use. For now, I feel that without extra input on the subject, I probably will keep the next version of the I-D on using NAPTR "SIP-O". Risks with TXT records seem rather high for the moment. Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 24.May.2006 10:41 >To: Fredrik Thulin; Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: sip@ietf.org >Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to=20 >rely on NAPTR orTXT records ? > >Fredrik, > >I tend to agree with you - TXT could very well become a can of=20 >wurms here > >Going back to the original problem: we wanted to have a way to=20 >discover=20 >outbound support. One scenario is that a client discovers a=20 >SIP outbound=20 >proxy through a DHCP option, resulting in an IP address or a=20 >DNS hostname. > >One thing to note here is that current clients in general=20 >don't have a way=20 >to lookup or prefer proxies with specific features. For=20 >example, they cannot=20 >choose RFC3261 proxies over non-RFC3261 proxies; they do not=20 >know in advance=20 >whether the discovered host(s) perform loose routing. For=20 >loose routing this=20 >is not a big problem; a client adds a 'lr' parameter anyway,=20 >and if it turns=20 >out to be a non-RFC3261 proxy, it will find out through the=20 >Record-Route=20 >header (or Path or Service-Route). And there are more cases=20 >like this (e.g.=20 >RFC3329 support, privacy services, ...) > >My suggestion for TXT was rooted in the expectation that we'll=20 >soon find=20 >ourselves with a need for discovery of other features too. The=20 >proposed=20 >NAPTR approach does not offer this. On the other hand, like Fredrik=20 >indicates - there is a danger of 'a great mess' > >Consider the following 2 options: >A) Use the hostname / IP discovered through DHCP as a key for=20 >DNS lookup >B) Extend the DHCP options used for SIP server discovery, to=20 >contain more=20 >than only the hostname > >A) What if we would simply take the DNS name (or IP address)=20 >discovered=20 >through DHCP, and feed it to a new NAPTR service - say H2U, for=20 >hostname-to-URI. This could perform a similar rewrite as DNS=20 >ENUM does, and=20 >return a sip: URI including flag parameters that indicate=20 >supported features=20 >(like 'lr' for loose routing, and 'ob' for outbound support). > >So for example: through DHCP client discovers=20 >'proxy.example.com' and does a=20 >NAPTR lookup >$ORIGIN proxy.example.com.sip.dhcp. > IN NAPTR 100 10 "u" "sip+H2U" "!^.*$!sip:proxy.example.com;lr;ob!" > >From this point on, things would be the same as if this URI had been=20 >provisioned manually. > >B) What seems to be causing this pain in the first place, is=20 >the limitations=20 >imposed by current DHCP options. Therefore another approach=20 >could be to=20 >define a new or extended DHCP option, supporting more than just the IP=20 >address or hostname (i.e. include outbound support flag there, and=20 >preferrably some mechanism for future options). > >Regards, >Jeroen > >----- Original Message -----=20 >From: "Fredrik Thulin" >To: >Cc: >Sent: Wednesday, May 24, 2006 8:36 AM >Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to=20 >rely on NAPTR=20 >orTXT records ? > > >> On Tuesday 23 May 2006 09:49, Erkki.Koivusalo@nokia.com wrote: >> ... >>> So I would like to get your comments or 'hum' for one option >>> or another. >> >> I hum loudly against TXT. The extendibility others have talked about >> will surely lead to a great mess, IMO. >> >> Maybe it isn't so unreasonable to define new values for=20 >NAPTR service, >> since the old ones are for SIP and the new ones are for SIP+STUN+more >> service? If it is, then perhaps the idea with DNS based=20 >provisioning of >> outbound SIP service isn't a good idea after all... >> >> /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=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 May 26 07:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fja2R-00087V-H7; Fri, 26 May 2006 06:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fja2Q-00087Q-4w for sip@ietf.org; Fri, 26 May 2006 06:59:26 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fja2O-00022t-QU for sip@ietf.org; Fri, 26 May 2006 06:59:26 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 8C40813F860; Fri, 26 May 2006 13:59:23 +0300 (EEST) Received: from rautu (in-vitro241.gprs.dnafinland.fi [62.78.121.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 0E2E513F6BC; Fri, 26 May 2006 13:59:18 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id B8B31F03C1; Fri, 26 May 2006 13:59:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17526.57219.598462.665341@rautu.tutpro.com> Date: Fri, 26 May 2006 13:59:15 +0300 From: Juha Heinanen To: Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> References: <007c01c67f05$55b46e90$31713b51@BEMBUSTER> <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com writes: > In my understanding SIP Outbound (with its additional STUN support > multiplexed to SIP port) is such a major discontinuity point, that > will not happen every day. From RFC 3261 onwards in my opinion there > is no other SIP extension that would be as essential for the UAs. i share this opinion and would like to get sip working group's focus on getting outbound and its discovery rfcs out as soon as possible. -- 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 May 26 08:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjbPJ-00023r-8T; Fri, 26 May 2006 08:27:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjbPH-00023m-Rt for sip@ietf.org; Fri, 26 May 2006 08:27:07 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjbPG-0001XF-GX for sip@ietf.org; Fri, 26 May 2006 08:27:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FjbP8-0001Lh-V4; Fri, 26 May 2006 07:26:59 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" , Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Fri, 26 May 2006 08:26:59 -0400 Message-ID: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <447633B3.60307@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaATVvxN0F+2vYrR0iqeOYNWXV5LwAcZASg 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: e1b0e72ff1bbd457ceef31828f216a86 Cc: 'Sip' , "'Vijay K. Gurbani'" , '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 My use case is real simple: A subscriber to a VoIP services is calling a subscriber at another VoIP service. The originating subscriber trusts his VoIP service proxies, = and is willing to trust the proxies in the terminating service. The reverse is true. The VoIP services peer. There may be a peering point proxy, but = if there is, the VoIP services trust it. There is very simple transitive trust all along the path. MITM is a possibility. Exchange between the peers may happen on the open = Internet. I think this is the kind of case we can construct a sips or sips-like=20 "TLS was used all the way" path. Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, May 25, 2006 6:46 PM To: jbemmel@zonnet.nl Cc: Sip; Vijay K. Gurbani; Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips jbemmel@zonnet.nl wrote: > Better to use a different name, e.g. SIPSEC=20 >=20 > SIPSS looks like SIPS misspelled. That=B4s a bad start for something intended to be secure : too easy for a user=20 > to make a typo While I agree in part, I don't think it is likely that many people will=20 be making secure phone calls by typing in SIPSS or SIPSEC URIs. Most=20 people don't type in HTTPS URIs either. Most of those are the result of=20 link following. I imagine secure phoning will be the same, or via some=20 sort of "secure" option button on a phone. In my practical experience, a web "session" is usually started using=20 HTTP, and then transitions to HTTPS later. I suppose something similar=20 might be possible with SIP: you could start a call with SIP and exchange = indications that SIPS is supported. Then one side could REFER/Replaces=20 the other side to a SIPS/SIPSS/SIPSEC URI that allows a secure session. I think we are badly in need of the use cases, so we can ensure that we=20 have a mechanism that supports them, rather than inventing a mechanism=20 that supports nothing useful. Paul > Regards, >=20 > jeroen >=20 > Citeren "Vijay K. Gurbani" : >=20 >> Dean Willis wrote: >>> I kind of like this. SIPSS: should either use a pass-through-TLS = (ala =20 >>> HTTP) or redirect-only model, require media encryption, two-way =20 >>> certification, and a few other things. How about an ID proposing the = =20 >>> requirements and the "what the user gets out of a lock icon" = discussion? >> OK. I will get one out before Montreal. >> >> Thanks, >> >> - vijay >> --=20 >> 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 >=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 Fri May 26 08:43:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbco-0002ty-NW; Fri, 26 May 2006 08:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbcn-0002tR-OE for sip@ietf.org; Fri, 26 May 2006 08:41:05 -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 1Fjbcn-0004TP-Mb for sip@ietf.org; Fri, 26 May 2006 08:41:05 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjbZq-00073i-Pv for sip@ietf.org; Fri, 26 May 2006 08:38:04 -0400 Received: by tutpro.com (Postfix, from userid 65534) id DDACF1401B9; Fri, 26 May 2006 15:38:00 +0300 (EEST) Received: from rautu (in-vitro241.gprs.dnafinland.fi [62.78.121.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id DE30E1401AD; Fri, 26 May 2006 15:37:50 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 85B0AF03C1; Fri, 26 May 2006 15:37:49 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17526.63132.789279.654812@rautu.tutpro.com> Date: Fri, 26 May 2006 15:37:48 +0300 From: Juha Heinanen To: "Brian Rosen" Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> References: <447633B3.60307@cisco.com> <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'Sip' , 'Paul Kyzivat' , 'Dean Willis' , "'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 Brian Rosen writes: > I think this is the kind of case we can construct a sips or sips-like > "TLS was used all the way" path. yes, if TLS is really used also between the last proxy and the called UAS, which is NOT currently mandated by rfc3261 and which jonathan suggested to be done. -- 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 May 26 09:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbvy-0007Go-Lk; Fri, 26 May 2006 09:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjbvx-0007Gj-Ag for sip@ietf.org; Fri, 26 May 2006 09:00:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjbvq-0007Fp-GD for sip@ietf.org; Fri, 26 May 2006 09:00:53 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E6D16A5E; Fri, 26 May 2006 15:00:45 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:00:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:00:45 +0200 Received: from [131.160.36.29] (EH3I2003TGFCPET.lmf.ericsson.se [131.160.36.29]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 35562264E; Fri, 26 May 2006 16:00:45 +0300 (EEST) Message-ID: <4476FBFD.8010508@ericsson.com> Date: Fri, 26 May 2006 16:00:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> <8C7CAACA-4217-4B5B-9078-B07BBD6F6123@cisco.com> In-Reply-To: <8C7CAACA-4217-4B5B-9078-B07BBD6F6123@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 13:00:45.0414 (UTC) FILETIME=[66D9E860:01C680C4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: SIP IETF , 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, the conclusion was the IETF wanted to have tighter control on SIP URI parameters than on header field parameters. Therefore, one would need a standards-track RFC in order to create new SIP URI parameters... that was the intent. Cheers, Gonzalo Cullen Jennings wrote: > > I'm glad to do that if the intent was relatively clear - if no one can > remember what it was, then I would like to ask the WG what it should > have been. I have not really tried to track down the history of this and > find out if the intent was clear. If you want me to do that first, or > have pointers to that, I will do that. > > > On May 22, 2006, at 3:26 PM, Dean Willis wrote: > >> >> Normally all it takes is a note from the AD saying "The IESG's intent >> was as specified by the second paragraph, standards-track RFC required". >> >> But we'll be happy to drive to WG Consensus if you want. Shall we >> document this in the form of an internet-draft? >> >> -- >> Dean >> >> >> On May 22, 2006, at 2:17 PM, Cullen Jennings wrote: >> >>> >>> This is clearly a bug in the spec. Would it be possible for the >>> chairs to drive this to WG consensus before or during next meeting, >>> get someone to file an errata, and then I will ask for IESG to review >>> and get IANA updated to match the errata. Sounds like a reasonable plan? >>> >>> Cullen >>> >>> >>> On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote: >>> >>>> I'd suggest that it probably should be standards track. URI >>>> parameters are a bigger deal than headers, I think, since they are >>>> really making changes to the fundamental SIP addressing >>>> architecture. I don't think that is something we want everyone doing. >>>> >>>> -Jonathan R. >>>> >>>> Cullen Jennings wrote: >>>> >>>>> On May 9, 2006, at 8:54 PM, Dean Willis wrote: >>>>>> >>>>>> RFC 3969 defines the registry for SIP/SIPS URI parameters. >>>>>> >>>>>> It currently says: >>>>>> >>>>>> 4.2. Registration Policy for SIP and SIPS URI Parameters >>>>>> >>>>>> As per the terminology in RFC 2434 [4], the registration policy >>>>>> for >>>>>> SIP and SIPS URI parameters shall be "Specification Required". >>>>>> >>>>>> For the purposes of this registry, the parameter for which IANA >>>>>> registration is requested MUST be defined by a standards-track >>>>>> RFC. >>>>>> >>>>>> >>>>>> Note that the above two paragraphs seem to be self contradictory. >>>>>> "Specification Required" means 3GPP and recognized bodies can >>>>>> define parameters by publishing specifications. But"Standards >>>>>> Track RFC" means only IETF can do so, and it has to be done with >>>>>> an IETF- consensus standards-track document. >>>>>> >>>>>> Note that the IANA registry currently says: >>>>>> >>>>>> >>>>>> SIP/SIPS URI Parameters RFC3969 Specification Required >>>>>> >>>>>> SIP/SIPS URI Parameters - per [RFC3969] >>>>>> (New registrations are via Specification Required) >>>>>> >>>>>> This means that the current IANA policy for this registry is >>>>>> "Specification Required". >>>>>> >>>>>> >>>>>> Which did we mean? >>>>> We might want to check with Allison on history of this but my >>>>> vague recollection was last time we discussed this, we decided we >>>>> meant "Standards Track". I forget the details and may be totally >>>>> wrong. >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP 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 -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~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 Fri May 26 09:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjciX-0005nv-2s; Fri, 26 May 2006 09:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjciV-0005kh-OL for sip@ietf.org; Fri, 26 May 2006 09:51:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjbtk-0006eJ-3e for sip@ietf.org; Fri, 26 May 2006 08:58:36 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjbg5-0007Ge-UH for sip@ietf.org; Fri, 26 May 2006 08:44:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Fjbfw-0002Gt-VV; Fri, 26 May 2006 07:44:21 -0500 From: "Brian Rosen" To: "'Juha Heinanen'" Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Fri, 26 May 2006 08:44:19 -0400 Message-ID: <016301c680c2$1e7e9220$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17526.63132.789279.654812@rautu.tutpro.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaAwUC/fMJrV4+QQOG5nQtEcdvRTwAALokQ 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: -2.4 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'Sip' , 'Paul Kyzivat' , 'Dean Willis' , "'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 Agree. If it's "TLS all along the path" then it includes the last hop. Brian -----Original Message----- From: Juha Heinanen [mailto:jh@tutpro.com] Sent: Friday, May 26, 2006 8:38 AM To: Brian Rosen Cc: 'Paul Kyzivat'; jbemmel@zonnet.nl; 'Sip'; 'Vijay K. Gurbani'; 'Dean Willis' Subject: RE: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Brian Rosen writes: > I think this is the kind of case we can construct a sips or sips-like > "TLS was used all the way" path. yes, if TLS is really used also between the last proxy and the called UAS, which is NOT currently mandated by rfc3261 and which jonathan suggested to be done. -- 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 May 26 10:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdXa-0001ze-3l; Fri, 26 May 2006 10:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdXW-0001xb-S3 for sip@ietf.org; Fri, 26 May 2006 10:43:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdIJ-0006Br-Ra for sip@ietf.org; Fri, 26 May 2006 10:28:09 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2006 10:28:03 -0400 X-IronPort-AV: i="4.05,177,1146456000"; d="scan'208"; a="89554045:sNHT33753744" 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 k4QES3TL000559; Fri, 26 May 2006 10:28:03 -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.211); Fri, 26 May 2006 10:28:02 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 10:28:02 -0400 Message-ID: <44771071.3020209@cisco.com> Date: Fri, 26 May 2006 10:28:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> In-Reply-To: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 May 2006 14:28:02.0476 (UTC) FILETIME=[986226C0:01C680D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'Sip' , 'Dean Willis' , "'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 Brian Rosen wrote: > My use case is real simple: > > A subscriber to a VoIP services is calling a subscriber at another VoIP > service. The originating subscriber trusts his VoIP service proxies, and is > willing to trust the proxies in the terminating service. The reverse is > true. The VoIP services peer. There may be a peering point proxy, but if > there is, the VoIP services trust it. > > There is very simple transitive trust all along the path. MITM is a > possibility. Exchange between the peers may happen on the open Internet. > > I think this is the kind of case we can construct a sips or sips-like > "TLS was used all the way" path. If we trust the proxies, then why don't we also trust them to make reliable connections for each hop? If a hop must go over the open internet then TLS is one way to ensure that it gets to the right place. If a hop takes place in some other environment there may be other ways to achieve the same guarantee. Its all based on trust in the proxies anyway, so why should we insist on TLS for *every* hop? And further, what was the point of going to this trouble if the media stream can't, or just isn't, secured? It seems like you end up with three degrees of security/privacy: 1) no confidence that you are connected to the intended party, and no confidence that your media stream is secure from snooping 2) confidence that you are connected to the intended party, but no confidence that your media stream is secure from snooping 3) confidence that you are connected to the intended party, and confidence that your media stream is secure from snooping How should an operator portray this to the user? a) tell the user nothing. let the user think that all calls are equally secure or insecure b) indicate which of the three cases applies to each call c) allow all three cases, but only use a binary security indicator: insecure for (1), secure for (2) and (3) d) allow all three cases, but only use a binary security indicator: insecure for (1) and (2), secure for (3) e) restrict the possibilities to no more than two, and then provide a binary indicator for which of the two cases applies. (E.g. don't permit (1), and provide a security indicator for (3)) f) restrict the possibilities to one, and provide no indicator Not all of these make sense. Any claim the operator makes had better be true, or it will be subject to lawsuits. If no indicator is given, then the operator had better only promise the worst case of what it supports. In that case, the operator has no incentive to provide more than what it claims to provide. (Why bother to provide security part of the time if you can't get any credit for it?) If a security indicator is given in some cases, then again it had better not over-promise. So all that can be promised is the worst case security that may be provided with that indicator. And there is again no incentive for the operator to provide more security than is promised. So ultimately it comes down to how many security variants it is possible to indicate, that users will understand. I think users can understand (1) and (3), but I am not at all sure users will be able to understand (2). I think the only way (2) makes sense is (e) where you don't permit any calls of type (1). There may be cases (e.g. military) where that is a viable option. But for general deployment in the next few years I question its viability. In the long run I think we should be aiming for all calls to be of type (3). Paul > Brian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, May 25, 2006 6:46 PM > To: jbemmel@zonnet.nl > Cc: Sip; Vijay K. Gurbani; Dean Willis > Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips > > > > jbemmel@zonnet.nl wrote: >> Better to use a different name, e.g. SIPSEC >> >> SIPSS looks like SIPS misspelled. That´s a bad start for something > intended to be secure : too easy for a user >> to make a typo > > While I agree in part, I don't think it is likely that many people will > be making secure phone calls by typing in SIPSS or SIPSEC URIs. Most > people don't type in HTTPS URIs either. Most of those are the result of > link following. I imagine secure phoning will be the same, or via some > sort of "secure" option button on a phone. > > In my practical experience, a web "session" is usually started using > HTTP, and then transitions to HTTPS later. I suppose something similar > might be possible with SIP: you could start a call with SIP and exchange > indications that SIPS is supported. Then one side could REFER/Replaces > the other side to a SIPS/SIPSS/SIPSEC URI that allows a secure session. > > I think we are badly in need of the use cases, so we can ensure that we > have a mechanism that supports them, rather than inventing a mechanism > that supports nothing useful. > > Paul > >> Regards, >> >> jeroen >> >> Citeren "Vijay K. Gurbani" : >> >>> Dean Willis wrote: >>>> I kind of like this. SIPSS: should either use a pass-through-TLS (ala >>>> HTTP) or redirect-only model, require media encryption, two-way >>>> certification, and a few other things. How about an ID proposing the >>>> requirements and the "what the user gets out of a lock icon" discussion? >>> OK. I will get one out before Montreal. >>> >>> 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 >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 26 10:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdZn-00032L-Uv; Fri, 26 May 2006 10:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjdZm-000305-VN for sip@ietf.org; Fri, 26 May 2006 10:46:06 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdZl-000271-M7 for sip@ietf.org; Fri, 26 May 2006 10:46:06 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4QEk4F9001625; Fri, 26 May 2006 09:46:04 -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 k4QEk4e15003; Fri, 26 May 2006 09:46:04 -0500 (CDT) Message-ID: <447714AC.5090401@lucent.com> Date: Fri, 26 May 2006 09:46:04 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> In-Reply-To: <4476D578.8080608@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Aki Niemi wrote: > Can you elaborate what use case you have that requires/benefits from > SIPS, then? Aki: See Jonathan's post on the benefits of sips: http://www1.ietf.org/mail-archive/web/sip/current/msg14342.html The use case revolves around trust in our intermediaries; Brian beat me to an an example. Obviously there are kinks to iron out, like securing the last hop. Dean has expressed an opinion that we should leave the last hop security specified as-is. So some work would be needed to reach consensus here. But let's take a look at a possible attack scenario across this transitive trust model. Before going deeper, I think we all agree that things like sdescriptions and keying materials should not be exchanged through a TLS-protected proxy chain. So, P1 --> P2 --> P3 --> P4 is a set of proxies. P1 sends request over TLS to P2. P2 lies and puts SIP/2.0/TLS in the Via header that it inserts, but sends it to P3 over TCP. P3 accepts request over TCP, notes that the topmost Via says TLS, but still continues to process the request towards P4! It could of course, reject the request right there, and thus stop this attack. For such a weak link attack to succeed, both P2 and P3 will have to conspire (or P3 would have to be a badly programmed proxy that does not know any better). Collusions such as this across autonomous network boundaries would be hard, I would think. Especially if the SIP proxies at P2 and P3 were of different genealogies. Thanks, - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 12:52:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfVY-0000OG-7P; Fri, 26 May 2006 12:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfVX-0000OB-DI for sip@ietf.org; Fri, 26 May 2006 12:49:51 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfVS-0008Ec-1i for sip@ietf.org; Fri, 26 May 2006 12:49:51 -0400 Received: by tutpro.com (Postfix, from userid 65534) id B030D1400CC; Fri, 26 May 2006 19:49:40 +0300 (EEST) Received: from rautu (in-vitro241.gprs.dnafinland.fi [62.78.121.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id D170E13F91A; Fri, 26 May 2006 19:49:28 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 01E17F03C1; Fri, 26 May 2006 19:49:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17527.12693.959315.99788@rautu.tutpro.com> Date: Fri, 26 May 2006 19:49:25 +0300 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <44771071.3020209@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'Sip' , 'Dean Willis' , "'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 Paul Kyzivat writes: > Its all based on trust in the proxies > anyway, so why should we insist on TLS for *every* hop? i remember reading just last week than NSA is splitting fibers between providers and capturing everything. sips MUST indicate to the end user that TLS is used on EVERY hop. > And further, what was the point of going to this trouble if the media > stream can't, or just isn't, secured? have you checked this: http://www.philzimmermann.com/EN/zfone/index.html end users can do it without any participation of proxies. - 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 May 26 12:52:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfWo-0000Tz-4K; Fri, 26 May 2006 12:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfWl-0000Tu-QG for sip@ietf.org; Fri, 26 May 2006 12:51:07 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfWk-0008Gb-GJ for sip@ietf.org; Fri, 26 May 2006 12:51:07 -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 k4QGp59W007620; Fri, 26 May 2006 11:51:05 -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 k4QGp5e28554; Fri, 26 May 2006 11:51:05 -0500 (CDT) Message-ID: <447731F9.8050305@lucent.com> Date: Fri, 26 May 2006 11:51:05 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> In-Reply-To: <44771071.3020209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'Sip' , '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: > If we trust the proxies, then why don't we also trust them to make > reliable connections for each hop? If a hop must go over the open > internet then TLS is one way to ensure that it gets to the right place. > If a hop takes place in some other environment there may be other ways > to achieve the same guarantee. Its all based on trust in the proxies > anyway, so why should we insist on TLS for *every* hop? This is essentially Dean's argument for leaving things alone at the last hop. The counter argument is that even the last hop must be protected by TLS. Some consensus would need to be reached. > And further, what was the point of going to this trouble if the media > stream can't, or just isn't, secured? Is a session less secure if h-b-h TLS is used for signaling and ZRTP, EKT, RTP/DTLS for media? Based on Dan Wing's analysis at the last raiarea meeting, I think the current thinking is to do key exchange for media in the media plane. Doing it in the signaling plane does not work well with services such as forking, or scenarios such as arrival of media before the SDP answer arrives in signaling. Furthermore, there will be services that are signaling only. The one that comes to mind is disseminating presence information. That does not require any media, but does require signaling confidentiality. It's probably best if e2e confidentiality is used, but I beleive h-b-h confidentiality across a trusted proxy chain would be adequate in a lot of cases. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 12:55:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfZE-00015J-9B; Fri, 26 May 2006 12:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjfZC-00010Z-2s for sip@ietf.org; Fri, 26 May 2006 12:53:38 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjfZA-00006r-OK for sip@ietf.org; Fri, 26 May 2006 12:53:38 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 3A08814014A; Fri, 26 May 2006 19:53:36 +0300 (EEST) Received: from rautu (in-vitro241.gprs.dnafinland.fi [62.78.121.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id AB8D9140105; Fri, 26 May 2006 19:53:30 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 959DFF03C1; Fri, 26 May 2006 19:53:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17527.12939.561077.447654@rautu.tutpro.com> Date: Fri, 26 May 2006 19:53:31 +0300 From: Juha Heinanen To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <447714AC.5090401@lucent.com> References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani writes: > Obviously there are kinks to iron out, like securing the last > hop. Dean has expressed an opinion that we should leave > the last hop security specified as-is. no way. my sip phone can connect to my providers proxy from anywhere in the world and i must be able to get that last hop protected is caller has specified 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 Fri May 26 13:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjffA-0000xw-Bg; Fri, 26 May 2006 12:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjff8-0000xq-AF for sip@ietf.org; Fri, 26 May 2006 12:59:46 -0400 Received: from mail.shinkuro.com ([216.194.124.237] helo=execdsl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjff4-0000Oh-VZ for sip@ietf.org; Fri, 26 May 2006 12:59:46 -0400 Received: from [69.17.17.130] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 13294728 for sip@ietf.org; Fri, 26 May 2006 10:57:54 -0600 Message-Id: <7.0.1.0.0.20060526125719.0330b620@stevecrocker.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 26 May 2006 12:59:33 -0400 To: 'Sip' From: "Joel M. Halpern" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <447731F9.8050305@lucent.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <447731F9.8050305@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 am missing something in this discussion. I have recently made changes so that I can use StartTLS for reading some of my email, and secure submission. I am not under any illusion that this protects my email end-to-end. But it is useful. SIPS gives me at least that much protection, and asks the proxies to attempt to provide more protection. This seems distinctly useful. Whether the icon should be a bunny carrying a lock, or some other icon, is really not a question for this group (I think.) Yours, Joel M. Halpern _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 26 13:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfq8-0002xy-Cj; Fri, 26 May 2006 13:11:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjfq6-0002xh-V9 for sip@ietf.org; Fri, 26 May 2006 13:11: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 1Fjfq6-0001wc-SM for sip@ietf.org; Fri, 26 May 2006 13:11:06 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjfq5-0002bb-1r for sip@ietf.org; Fri, 26 May 2006 13:11:06 -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 k4QHB42M018490 for ; Fri, 26 May 2006 12:11:04 -0500 (CDT) Received: from [135.185.244.44] (ihgp244n44.ih.lucent.com [135.185.244.44]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k4QHB4e16640; Fri, 26 May 2006 12:11:04 -0500 (CDT) Message-ID: <447738A5.6070503@bell-labs.com> Date: Fri, 26 May 2006 12:19:33 -0500 From: Alan Jeffrey User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sip Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> In-Reply-To: <447714AC.5090401@lucent.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: 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="===============0901494318==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0901494318== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030009060101020202020306" This is a cryptographically signed message in MIME format. --------------ms030009060101020202020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some thoughts on the requirements for SIPS... It seems to me that there are two distinct scenarios: SIPS between hosts in the same administrative domain, and SIPS across administrative domains. RFC3261 already distinguishes these in the special case of the final proxy<->UE hop, but doesn't do so between proxies in the middle of the network. In the case of SIPS crossing administrative domain, there is a clear argument for requiring some form of encryption: whether that's TLS-only or allows DTLS, IPsec, or other means is still up for argumentation, but the case for integrity and confidentiality protection is clear. Less clear is the case within one administrative domain. Examples where it might make sense to allow intra-domain SIPS traffic to be transported unencrypted include: a) SIPS traffic from a proxy to an application server such as voice mail: especially in the case where the AS is physically located in the same secured room. It seems odd to require the traffic to be encrypted, then re-encrypted to travel a few feet across an ethernet cable in a locked room :-) b) Proxy farms which use an external TLS accelerator to offload the TLS. In the HTTP world, these are often deployed non-transparently, meaning that the TLS accelerator acts as a proxy, speaking HTTPS externally and HTTP internally. (Microsoft has added a Front-End-Https header to HTTP to notify the back-end server that the external connection was TLS-secured, although it passes little information about the state of the TLS connection, e.g. the certificate chain authenticating it.) In cases like these, I'd find it difficult to argue that the additional security guarantees of TLS are worth the expense. Just my tuppence worth... Alan. PS: Shouldn't the "hop-by-hop bunny" icon use the rabbit from Monty Python and the Holy Grail? -- Alan Jeffrey +1 630 224 0175 Bell Labs, Lucent Technologies http://cm.bell-labs.com/who/ajeffrey/ --------------ms030009060101020202020306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJZzCC Aw4wggJ3oAMCAQICAw+fEDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2 WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRwwGgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQw IgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVzdGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFq ZWZmcmV5QGJlbGwtbGFicy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw 5Cul6gbCRPip8crm2iiMo6nYik6LiQLaF6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqv GMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6+mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN 7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dvKRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68 Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjloUeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ 7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNOJLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1Ud EQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQATaJTPOE4MEgjz7MOKXa7HsDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKik hhgSy41MWfIb/thRzvdN2qX4diPDuXCUW1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRx yCAzL3REtosiDHKfc+CzagJAuDfJgTbel6LIaTCCAw4wggJ3oAMCAQICAw+fEDANBgkqhkiG 9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew HhcNMDUxMDEwMDE0NzM2WhcNMDYxMDEwMDE0NzM2WjB9MRAwDgYDVQQEEwdKZWZmcmV5MRww GgYDVQQqExNBbGFuIFN0ZXdhcnQgQXVzdGluMSQwIgYDVQQDExtBbGFuIFN0ZXdhcnQgQXVz dGluIEplZmZyZXkxJTAjBgkqhkiG9w0BCQEWFmFqZWZmcmV5QGJlbGwtbGFicy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDw5Cul6gbCRPip8crm2iiMo6nYik6LiQLa F6gjTkhh0qs0ez2KtdxKmswHiuf7yZISvmvAGfqvGMsWrQejVvV7DlL2Tn2XL68FuFv6Sco6 +mnM7tcRt5zjXpEyLwPzn1OFfoHW0CWxeM/LMrEN7BIhUhzz4ZnFCYf0t1ws+sZH5YEwa2dv KRsxe9ThA1VwL9pWbfJxqtK2ETw7myV4/SdOJP68Y0mAdXNw+LjmSCetvYxcg9K8YLGjpjlo UeamGYU9v3LXznKUrXWaagU13XYYqOjt0Nv0awwJ7Gn5fKTNEhLIfmA7w0CbrOzH+qhxQPNO JLbeQx9H/ySTHMFy3dLnAgMBAAGjMzAxMCEGA1UdEQQaMBiBFmFqZWZmcmV5QGJlbGwtbGFi cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQATaJTPOE4MEgjz7MOKXa7H sDzy/HyG29dlufCT/rQRvslmd3iibxAI5B1/vKikhhgSy41MWfIb/thRzvdN2qX4diPDuXCU W1wpsOeh9QU0qwvCda8311iIljiRqs7VKEN9bVRxyCAzL3REtosiDHKfc+CzagJAuDfJgTbe l6LIaTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMAkGBSsOAwIaBQCgggGn MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDUyNjE3MTkz M1owIwYJKoZIhvcNAQkEMRYEFDvR0IGwIanz1UFo8ax5Ip8eY4qSMFIGCSqGSIb3DQEJDzFF MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMPnxAwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD58QMA0GCSqGSIb3 DQEBAQUABIIBALYodVIjR28KQUmxWo7bTdEhtVqJWrENSXPuv8zJMT5S+yJ6SIDbKLSc7TSs rMzKn14C51LzX6EN6D6YGpD2o527UM4ipPMxBzOMmZbDkgfJYBAECsmuAgugGuYZ80wG9wM4 iNoS+ywiYRguQq1GFzN0ok86BuDL0K5MJKraWI78+sGIUcY+L7xVQPnp/KVd/aVQxcCsOOpp fjHXO8c4v+/xwHyOQHmRn/DTL99kD6FfIMPmP5oTNJ7QIg+lbFqctbfp2s3HXRs0mzoZ1Nnr YW+M5He+jzMwCYK1Nt77882phFswe27B+we5e7pmG8A0j9u09K8AUWMtxSPQ9mGbTl0AAAAA AAA= --------------ms030009060101020202020306-- --===============0901494318== 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 --===============0901494318==-- From sip-bounces@ietf.org Fri May 26 16:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiaL-0002pm-OH; Fri, 26 May 2006 16:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjiaH-0002dx-6F; Fri, 26 May 2006 16:06:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjiaH-0007KJ-4l; Fri, 26 May 2006 16:06:57 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjiSl-0004ND-Od; Fri, 26 May 2006 15:59:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4QJo167013563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FjiJt-0005fV-Nb; Fri, 26 May 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, 26 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-certs-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 : Certificate Management Service for The Session Initiation Protocol (SIP) Author(s) : C. Jennings, et al. Filename : draft-ietf-sip-certs-00.txt Pages : 29 Date : 2006-5-26 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. 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-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-certs-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-certs-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-5-26140557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-certs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-certs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-26140557.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 May 26 16:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjiql-0003I3-41; Fri, 26 May 2006 16:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjiqk-0003Hd-3I for sip@ietf.org; Fri, 26 May 2006 16:23:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjiqk-00081W-1t for sip@ietf.org; Fri, 26 May 2006 16:23:58 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjiob-00054K-GE for sip@ietf.org; Fri, 26 May 2006 16:21:45 -0400 Received: (qmail 5560 invoked by uid 0); 26 May 2006 20:21:40 -0000 Received: from unknown (HELO webmail.zonnet.nl) ([10.170.1.95]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 May 2006 20:21:40 -0000 Received: by webmail.zonnet.nl (Postfix, from userid 33) id 0F19D940; Fri, 26 May 2006 22:21:44 +0200 (CEST) Received: from 81.59.178.113 ( [81.59.178.113]) as user jbemmel@localhost by webmail.versatel.nl with HTTP; Fri, 26 May 2006 22:21:43 +0200 Message-ID: <1148674903.44776357ecd0e@webmail.versatel.nl> Date: Fri, 26 May 2006 22:21:43 +0200 From: jbemmel@zonnet.nl To: "Erkki.Koivusalo@nokia.com" Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? References: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 81.59.178.113 X-Spam-Score: -2.2 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "sip@ietf.org" , "ft@it.su.se" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, > > What comes to the approach to use DNS for automatically discovering > the proxies supporting SIP Outbound: > > >One thing to note here is that current clients in general > >don't have a way to lookup or prefer proxies with specific features. > > I would challenge this by claiming that before draft-ietf-sip-outbound > the clients did not have any strong reason to do so. But my opinion > is that the strong reason has emerged with SIP Outbound, which is > essential to enable the UA to traverse NAT to use any feature of SIP. > In other words, you agree with what I say above, but stipulate that until outbound there was no real need for it either. So then the question is: is there a need for something generic, or will something that only works for outbound suffice? I can think of several SIP features that could benefit from a discovery capability: SIP Identity, SIP Privacy (RFC3323), Security Mechanism agreement (RFC3329) to name a few (and perhaps proxies that will support the new to-be-defined SIPS security model). I understand Juha when he says "focus on outbound + discovery now". On the other hand, from the discussion so far I also sense that we haven't got all the requirements clear yet. My fear is that we'll end up with something that sort of works for outbound, but breaks as soon as we stumble upon a next 'discontinuity point' (say, SIPSEC) that UACs also consider as 'critical'. Then how would they go about discovering a proxy that supports outbound + SIPSEC? I don't have the solution, but my gut feeling is that neither NAPTR SIP-O nor TXT records will do us much good in the long run. Ultimately we will need a SIP-based mechanism here. As for the next version of the discovery draft: I think a section on the requirements that we're trying to meet (and also those that we're not) would be good. Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 16:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjivN-00077J-5E; Fri, 26 May 2006 16:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjivM-00070f-1A for sip@ietf.org; Fri, 26 May 2006 16:28:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjirS-00083i-QK for sip@ietf.org; Fri, 26 May 2006 16:24:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjid8-0004qu-6V for sip@ietf.org; Fri, 26 May 2006 16:09:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 May 2006 13:09:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4QK9rt9008359; Fri, 26 May 2006 13:09:53 -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 k4QK9qB9025570; Fri, 26 May 2006 13:09:52 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QK6lT1022327; Fri, 26 May 2006 13:06:48 -0700 Message-ID: <44776099.6080201@cisco.com> Date: Fri, 26 May 2006 13:10:01 -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: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> In-Reply-To: <17527.12693.959315.99788@rautu.tutpro.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=402; t=1148674193; x=1149538193; c=relaxed/simple; s=sjdkim3001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=Rsrz4KY7BsLTWCACJqIB8maXM9fBRD5mZkLBOpYBLDX9m75NGq5q4Z5+xNmG9iwDp6DcYbAi ecRKpnzuvIuT7D3C4DCXbiYVml/ubW3I22Xz3wMSSovbx2amtZuBmhDI; X-Spam-Score: -2.6 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'Sip' , Paul Kyzivat , "'Vijay K. Gurbani'" , '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 Juha Heinanen wrote: >Paul Kyzivat writes: > > > Its all based on trust in the proxies > > anyway, so why should we insist on TLS for *every* hop? > >i remember reading just last week than NSA is splitting fibers between >providers and capturing everything. sips MUST indicate to the end user >that TLS is used on EVERY hop. > > For some value of EVERY. Namely, one. 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 May 26 16:37:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjj20-0004kP-Cn; Fri, 26 May 2006 16:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjj1y-0004kE-FS for sip@ietf.org; Fri, 26 May 2006 16:35:34 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjj1x-00018K-6k for sip@ietf.org; Fri, 26 May 2006 16:35:34 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 May 2006 13:35:32 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4QKZW9m030143; Fri, 26 May 2006 13:35:32 -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 k4QKZWB9019230; Fri, 26 May 2006 13:35:32 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QKWRKg022893; Fri, 26 May 2006 13:32:28 -0700 Message-ID: <4477669E.4@cisco.com> Date: Fri, 26 May 2006 13:35:42 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> In-Reply-To: <447714AC.5090401@lucent.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=1062; t=1148675732; x=1149539732; c=relaxed/simple; s=sjdkim3001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=Q2SqiTG7VnwIhbDAy+25efFsxfPRvVdxgWT7YUH5nFnbXyyPrwHg3J0ng9e1pchcr8ZQpj1V 8UMRRnj4zqxTIIKvARZ7Vsp/Krea874J81k4/hJYCdZkktg+Z2NG+ZYu; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Sip , Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > > So, P1 --> P2 --> P3 --> P4 is a set of proxies. P1 sends > request over TLS to P2. P2 lies and puts SIP/2.0/TLS in > the Via header that it inserts, but sends it to P3 over TCP. > P3 accepts request over TCP, notes that the topmost Via says > TLS, but still continues to process the request towards > P4! It could of course, reject the request right there, and > thus stop this attack. For such a weak link attack to succeed, > both P2 and P3 will have to conspire (or P3 would have to be a > badly programmed proxy that does not know any better). > Collusions such as this across autonomous network boundaries > would be hard, I would think. Especially if the SIP proxies at > P2 and P3 were of different genealogies. > The more I think about this the more I do know what real life problem SIPS thinks it's solving. Can somebody be so kind as to tell me? Not what SIPS might provide, but what real life attacks it prevents that are uniquely due to SIPS (ie, different from transport=tls). 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 May 26 17:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjOH-0004Av-Hx; Fri, 26 May 2006 16:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjOF-0004Aq-U8 for sip@ietf.org; Fri, 26 May 2006 16:58:35 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjjOE-0004Mp-Js for sip@ietf.org; Fri, 26 May 2006 16:58:35 -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 k4QKwXCD003290; Fri, 26 May 2006 15:58:33 -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 k4QKwXe22023; Fri, 26 May 2006 15:58:33 -0500 (CDT) Message-ID: <44776BF9.1070402@lucent.com> Date: Fri, 26 May 2006 15:58:33 -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: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> <4477669E.4@cisco.com> In-Reply-To: <4477669E.4@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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: , Content-Type: multipart/mixed; boundary="===============1796557234==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1796557234== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000506020905080402010603" This is a cryptographically signed message in MIME format. --------------ms000506020905080402010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Thomas wrote: > The more I think about this the more I do know what real life > problem SIPS thinks it's solving. Can somebody be so kind as to > tell me? Not what SIPS might provide, but what real life attacks > it prevents that are uniquely due to SIPS (ie, different from > transport=tls). For this particular attack, assume that you did not have sips; only transport=tls. Then, there would not be a way for P1 to indicate to P2 that P2 should use TLS towards P3 (since the informal consensus in the group appears to be that transport=tls, were it resurrected, would mean protect the traffic towards the next hop only). With sips, at the very least, you have the notion that all well behaving intermediaries would use TLS towards the destination. If we do away with the notion of upgrading sip URI to sips and disallow downgrading sips to sip, at least a host receiving a request with a sips URI can be certain that TLS was used on every hop. Now, as a matter of course, we could do away with sips by making TLS the preferred transport such that all entities used TLS first (over any transport that supports it), before trying a non-TLS transport. But then you loose the ability to know whether TLS was used at every hop. 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) --------------ms000506020905080402010603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjYyMDU4MzNaMCMGCSqGSIb3DQEJ BDEWBBQ7MtVGuSqU1JWXisZgGeu5knRzlzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAW0BruYUmR6g8UbCv6Zp15z2vGkDdsbYzBT54QECZURj220mpoR8s +0wo037CMEgini/0C8j4yOo2BnggbmPeB7co0vEl5EBenBp4HeuBaz2hpPVcpWfBYI8STOD5 uN2AHpJ5PKETmakXWbo8DqZzts2+RDLMbnwnzgZX1j10AxEAAAAAAAA= --------------ms000506020905080402010603-- --===============1796557234== 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 --===============1796557234==-- From sip-bounces@ietf.org Fri May 26 17:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjOw-0004T6-IM; Fri, 26 May 2006 16:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjOv-0004Sq-39 for sip@ietf.org; Fri, 26 May 2006 16:59:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjjOs-0004OA-Nt for sip@ietf.org; Fri, 26 May 2006 16:59:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 13:59:14 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="1813730681:sNHT37429122" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4QKxEcv024908 for ; Fri, 26 May 2006 13:59:14 -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 k4QKxEB7013424 for ; Fri, 26 May 2006 13:59:14 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QKu9mx023414 for ; Fri, 26 May 2006 13:56:10 -0700 Message-ID: <44776C2C.1030000@cisco.com> Date: Fri, 26 May 2006 13:59:24 -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 CC: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-certs-00.txt References: In-Reply-To: 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=3188; t=1148677154; x=1149541154; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20I-D=20ACTION=3Adraft-ietf-sip-certs-00.txt; X=v=3Dcisco.com=3B=20h=3Dd/m8G4poDc5YBnPo24zb23POYro=3D; b=nhR718VIfDPRTQw2AdMKT0+I6g5wOZgSX+ebVvVXYyayNCTvHJjZ0fQLXXSCx0tg505fOlct 1Kls0VgvhKuMVBzpVroLjxF/hx5igX9ietqyJk7PuetIQyg21XcxyllK; X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Do I undesrstand correctly that you want to store _private_ keys in this thing? Oi. Second, why is this being done in the SIP working group? It sure seems like it's out of the realm of this working group's expertise. See above. Mike 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 : Certificate Management Service for The Session Initiation Protocol (SIP) > Author(s) : C. Jennings, et al. > Filename : draft-ietf-sip-certs-00.txt > Pages : 29 > Date : 2006-5-26 > >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. 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-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-certs-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-certs-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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 26 17:03:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjRc-0005JL-Et; Fri, 26 May 2006 17:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjRb-0005JG-Pq for sip@ietf.org; Fri, 26 May 2006 17:02:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjjRZ-0004e3-Gf for sip@ietf.org; Fri, 26 May 2006 17:02:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 May 2006 14:02:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4QL21Eb023131; Fri, 26 May 2006 14:02:01 -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 k4QL20B9012823; Fri, 26 May 2006 14:02:00 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4QKwuwD023481; Fri, 26 May 2006 13:58:56 -0700 Message-ID: <44776CD3.1070500@cisco.com> Date: Fri, 26 May 2006 14:02:11 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> <4477669E.4@cisco.com> <44776BF9.1070402@lucent.com> In-Reply-To: <44776BF9.1070402@lucent.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=1424; t=1148677321; x=1149541321; c=relaxed/simple; s=sjdkim3001; 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]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5ZYFYTv6il2g2E0+AcczPyOKcQM=3D; b=gsJxpsatL+hfCHCd72dcp91x58MAmVsSp41aal2Awald1UwwRFSBj6qXozrU9V0XqVrUcc9c y9cwlY1Ij3rhIN2uyGAfA3nzcBjNHwnCJpOz3qv5j77j/vLxp5+zwufo; X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Vijay K. Gurbani wrote: > Michael Thomas wrote: > >> The more I think about this the more I do know what real life >> problem SIPS thinks it's solving. Can somebody be so kind as to >> tell me? Not what SIPS might provide, but what real life attacks >> it prevents that are uniquely due to SIPS (ie, different from >> transport=tls). > > > For this particular attack, [...] What particular attack? Mike > assume that you did not have sips; > only transport=tls. Then, there would not be a way for P1 > to indicate to P2 that P2 should use TLS towards P3 (since > the informal consensus in the group appears to be that > transport=tls, were it resurrected, would mean protect the > traffic towards the next hop only). > > With sips, at the very least, you have the notion that all > well behaving intermediaries would use TLS towards the > destination. If we do away with the notion of upgrading sip > URI to sips and disallow downgrading sips to sip, at least a > host receiving a request with a sips URI can be certain that > TLS was used on every hop. > > Now, as a matter of course, we could do away with sips by > making TLS the preferred transport such that all entities > used TLS first (over any transport that supports it), before > trying a non-TLS transport. But then you loose the ability > to know whether TLS was used at every hop. > > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 17:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjnO-0003Px-FV; Fri, 26 May 2006 17:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjnM-0003AT-F0 for sip@ietf.org; Fri, 26 May 2006 17:24:32 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjjYl-0005Yp-5g for sip@ietf.org; Fri, 26 May 2006 17:09:28 -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 k4QL9QH4007505; Fri, 26 May 2006 16:09:26 -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 k4QL9Pe29291; Fri, 26 May 2006 16:09:25 -0500 (CDT) Message-ID: <44776E85.2000800@lucent.com> Date: Fri, 26 May 2006 16:09: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: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> <4477669E.4@cisco.com> <44776BF9.1070402@lucent.com> <44776CD3.1070500@cisco.com> In-Reply-To: <44776CD3.1070500@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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: , Content-Type: multipart/mixed; boundary="===============1286947756==" Errors-To: sip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1286947756== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000305000800030202080305" This is a cryptographically signed message in MIME format. --------------ms000305000800030202080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Thomas wrote: >> >> For this particular attack, [...] > > What particular attack? The one you had replied to in my email ... let me see -- the mail archive is not yet updated, so I will cut-and-paste from your previous email: Michael Thomas wrote: > Vijay K. Gurbani wrote: > >> >> So, P1 --> P2 --> P3 --> P4 is a set of proxies. P1 sends request >> over TLS to P2. P2 lies and puts SIP/2.0/TLS in the Via header >> that it inserts, but sends it to P3 over TCP. P3 accepts request >> over TCP, notes that the topmost Via says TLS, but still continues >> to process the request towards P4! It could of course, reject the >> request right there, and thus stop this attack. For such a weak >> link attack to succeed, both P2 and P3 will have to conspire (or P3 >> would have to be a badly programmed proxy that does not know any >> better). Collusions such as this across autonomous network >> boundaries would be hard, I would think. Especially if the SIP >> proxies at P2 and P3 were of different genealogies. >> > The more I think about this the more I do know what real life problem > SIPS thinks it's solving. Can somebody be so kind as to tell me? Not > what SIPS might provide, but what real life attacks it prevents that > are uniquely due to SIPS (ie, different from transport=tls). > > Mike 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) --------------ms000305000800030202080305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIkNjCC CZowggiCoAMCAQICChq5SpYAAAAABscwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA0MDYyMzIwMDM0MVoXDTA2MDYyMzIwMTM0MVowQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8/1oQRIU0sF4rsiC0F6mQu6TSvQPCRl6BObQcR58a 5swju1dVwTz3XbON9p5qjYRqxm9d+OX7W2Bj68dxlYUTz5yp9KkwH7hNLVTy09E3dwdZM36L +7ICKUK9M6YU64MJAGTg1tTxUIxflKy0SMCPJIldiEp/JrXYb2aVhmW8tQIDAQABo4IGpDCC BqAwHQYDVR0OBBYEFFG9/4w6CpUIC+mXdQWpWuBH+nkbMIH+BgNVHSMEgfYwgfOAFISfQVWc EIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1 Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBB dXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPyLGQBAQQFFgN2a2cwFwYKCZImiZPyLGQB LAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBzCCAncGCCsGAQUFBwEBBIICaTCCAmUw gc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNlYXN0LnBvc3QubHVjZW50LmNvbS9jbj1M dWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBwgYIKwYB BQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHMBggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFw LWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIICgTCCAn0wgdaggdOggdCGgc1sZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDov L2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0 ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xh c3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEu cG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRl JTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IBAQBZ1m98/KuOGemr fAEgtDWIiZjKEN3ShsKT3bfKvjw/zSOtL2UpwNab9xqHKdV9rt4O0wzx6By/0JY/hCQrPMAm YCO0Xo14fC8OSzRkRl1kSPn0E+v8vD+dn42a+dBdmN2SD56jg7/EkvifgaCw9n/HMi4vXcOS +RUdxZkPRnYLyh4GiocnBx88IQEzWK9shMLzC7gm3K6V6kggUSchxR703OHNTLb7XKeEDzSX LdXMVHA5N89xTQGyVWk8Mc6fO7icn0LthC81Ig0/M6v12Vmb2+Tdq7aB7ZVgaU95f/eezcHh LgaYlutde9q6s+c8ok8/hI2VBcGMt85Apf5GAktoMIIJmjCCCIKgAwIBAgIKGrlKlgAAAAAG xzANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50 LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJh eSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQg VGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwHhcNMDQwNjIzMjAwMzQxWhcN MDYwNjIzMjAxMzQxWjBBMR0wGwYJKoZIhvcNAQkBFg52a2dAbHVjZW50LmNvbTEgMB4GA1UE AxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALz/WhBEhTSwXiuyILQXqZC7pNK9A8JGXoE5tBxHnxrmzCO7V1XBPPdds432nmqNhGrGb134 5ftbYGPrx3GVhRPPnKn0qTAfuE0tVPLT0Td3B1kzfov7sgIpQr0zphTrgwkAZODW1PFQjF+U rLRIwI8kiV2ISn8mtdhvZpWGZby1AgMBAAGjggakMIIGoDAdBgNVHQ4EFgQUUb3/jDoKlQgL 6Zd1Bala4Ef6eRswgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcsw gcgxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVT MRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMT THVjZW50IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkG A1UEAxMiTHVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTAT BgoJkiaJk/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4 QgEBBAQDAgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQG CCsGAQUFBwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8v bGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUy MENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1 Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2 aWNlcyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9j YWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRo b3JpdHkwgcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmlj YXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKK BgNVHR8EggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNl cyUyMDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0 aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmlj YXRpb25BdXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNl cnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZv Y2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MIHUoIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9j YXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBAFnWb3z8q44Z6at8ASC0NYiJmMoQ3dKGwpPdt8q+PD/N I60vZSnA1pv3Gocp1X2u3g7TDPHoHL/Qlj+EJCs8wCZgI7RejXh8Lw5LNGRGXWRI+fQT6/y8 P52fjZr50F2Y3ZIPnqODv8SS+J+BoLD2f8cyLi9dw5L5FR3FmQ9GdgvKHgaKhycHHzwhATNY r2yEwvMLuCbcrpXqSCBRJyHFHvTc4c1Mtvtcp4QPNJct1cxUcDk3z3FNAbJVaTwxzp87uJyf Qu2ELzUiDT8zq/XZWZvb5N2rtoHtlWBpT3l/957NweEuBpiW61172rqz5zyiTz+EjZUFwYy3 zkCl/kYCS2gwghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMT Ikx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcN MTAxMjA2MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNv bTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBI aWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVj aG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+ JXW723615PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHE x5xRWAiONeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJ E3BGQTOX0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46C ZQsibysVefigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMB AAGjggz0MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4h S09K38swCwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/h K1C+quh9NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0 eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsT E0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9v dCBBdXRob3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCB xoaBw2xkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVj aG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9y aXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jh c2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6 Ly9sZGFwLXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVz JTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0 Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4 dGVybmFsLmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1 dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2Nl cnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0 Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlm aWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRp b25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcqggceggcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQl MjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBB dXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/ bGRhcDovL2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2ll cyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89 bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJp dHkubHVjZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYB BQUHMAKGgbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVj dGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xk YXAtdXN3ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBS b290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2Vu dC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7 YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYB BQUHMAKGgbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUy MEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29i amVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDov L2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIw Um9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNl bnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNh dGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVj ZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0 ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggr BgEFBQcwAoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRo b3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3Rj bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNl Y3VyaXR5Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5Urds B2nOxTrekCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82 gm7eZee7lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13 h4tgCPG3WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biR Zr61dWmQWajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb 1QUPqg8/g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCA8kwggPFAgEBMIHBMIGyMSUw IwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEG A1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNh dGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA1MjYyMTA5MjVaMCMGCSqGSIb3DQEJ BDEWBBQncJHg+R5dMP5dr7GidJMvACEJjDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCB0gYJKwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5s dWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxML TXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1 Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKGrlKlgAAAAAGxzCB 1AYLKoZIhvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1 Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtN dXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVj ZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoauUqWAAAAAAbHMA0G CSqGSIb3DQEBAQUABIGAd8p+rcD+Wvmkei0oWAvztOK1B36aj6eSdEbD0jN7Y475PPCMRuBH /5C6do2+XPRBxsIW+AZx1tN0l6IK9edqeTXMq6UaDse9qBFrGTN3EYn4kGGyGUthFlbjFd2Z kViH5yFm6CU8bqQwMBhk11gSYfZNZHw/pqeXXzmv4XoImU8AAAAAAAA= --------------ms000305000800030202080305-- --===============1286947756== 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 --===============1286947756==-- From sip-bounces@ietf.org Fri May 26 18:17:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjkaU-0007Et-0b; Fri, 26 May 2006 18:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjkaS-0007Eg-DK for sip@ietf.org; Fri, 26 May 2006 18:15:16 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjkaP-0005UZ-V8 for sip@ietf.org; Fri, 26 May 2006 18:15:16 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 26 May 2006 15:15:12 -0700 X-IronPort-AV: i="4.05,178,1146466800"; d="scan'208"; a="1813784684:sNHT32551096" 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/8.12.11) with ESMTP id k4QMFCJT011392; Fri, 26 May 2006 15:15:12 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4QMFCsF006906; Fri, 26 May 2006 15:15:12 -0700 (PDT) Received: from [192.168.1.2] ([10.21.89.39]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:15:10 -0700 In-Reply-To: <44776C2C.1030000@cisco.com> References: <44776C2C.1030000@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AC94CAD-9B95-4B5F-AE77-B8D6F295C4D3@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-certs-00.txt Date: Fri, 26 May 2006 15:15:08 -0700 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 26 May 2006 22:15:10.0949 (UTC) FILETIME=[DAA7B950:01C68111] DKIM-Signature: a=rsa-sha1; q=dns; l=3957; t=1148681712; x=1149545712; c=relaxed/simple; s=sjdkim8001; 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=20ACTION=3Adraft-ietf-sip-certs-00.txt; X=v=3Dcisco.com=3B=20h=3D2nrKRplXFE3lAT4YF3gbLxYhZbk=3D; b=Aj6dlxFdd27Fw9a/xKmm3NPJev2u49fT8APc6+FfD9AvalTce6nP/0gx9S5EZJcku8JswiKe 8mdgW6x/lltAwgky0HLeNQ0bLugQMxfGI6NzjMLnkCFJddRC7er6aWRX; 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: 5011df3e2a27abcc044eaa15befcaa87 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 Jon and I talked to the Security ADs and the various SIP and SIPPING chairs to try and figure out best place for it. Clearly it needs security review. There was no idea location but this seemed as good as any. On May 26, 2006, at 1:59 PM, Michael Thomas wrote: > Do I undesrstand correctly that you want to store _private_ keys in > this thing? Oi. > > Second, why is this being done in the SIP working group? It sure > seems like it's > out of the realm of this working group's expertise. See above. > > Mike > > 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 : Certificate Management Service for The Session >> Initiation Protocol (SIP) >> Author(s) : C. Jennings, et al. >> Filename : draft-ietf-sip-certs-00.txt >> Pages : 29 >> Date : 2006-5-26 >> >> 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. 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-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-certs-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-certs-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 >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 26 18:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjkl9-0001OX-O3; Fri, 26 May 2006 18:26:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjkl6-0001Ml-OB; Fri, 26 May 2006 18:26:16 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjkl5-0005lI-C7; Fri, 26 May 2006 18:26:16 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4QMQEjZ007497; Fri, 26 May 2006 15:26:14 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4QMQEFT007496; Fri, 26 May 2006 15:26:14 -0700 Date: Fri, 26 May 2006 15:26:14 -0700 Message-Id: <200605262226.k4QMQEFT007496@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4508 on Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4508 Title: Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method Author: O. Levin, A. Johnston Status: Standards Track Date: May 2006 Mailbox: oritl@microsoft.com, ajohnston@ipstation.com Pages: 6 Characters: 11338 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-refer-feature-param-01.txt URL: http://www.rfc-editor.org/rfc/rfc4508.txt The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 26 19:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjlLk-0005eQ-KX; Fri, 26 May 2006 19:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjlLj-0005eL-HS for sip@ietf.org; Fri, 26 May 2006 19:04:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjlLh-0002cG-66 for sip@ietf.org; Fri, 26 May 2006 19:04:07 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 May 2006 16:04:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,178,1146466800"; d="scan'208"; a="29064209:sNHT21967908" 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 k4QN44TL026607; Fri, 26 May 2006 19:04:04 -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.211); Fri, 26 May 2006 19:04:04 -0400 Received: from [161.44.79.123] ([161.44.79.123]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 19:04:03 -0400 Message-ID: <44778963.9000102@cisco.com> Date: Fri, 26 May 2006 19:04:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> In-Reply-To: <17527.12693.959315.99788@rautu.tutpro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 23:04:03.0607 (UTC) FILETIME=[AEA7D270:01C68118] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Sip' , 'Dean Willis' , "'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 Juha Heinanen wrote: > Paul Kyzivat writes: > > > Its all based on trust in the proxies > > anyway, so why should we insist on TLS for *every* hop? > > i remember reading just last week than NSA is splitting fibers between > providers and capturing everything. sips MUST indicate to the end user > that TLS is used on EVERY hop. > > > And further, what was the point of going to this trouble if the media > > stream can't, or just isn't, secured? > > have you checked this: > > http://www.philzimmermann.com/EN/zfone/index.html > > end users can do it without any participation of proxies. I guess it depends on what your goals are. That approach is probably good in the case where you actually have keys for the people you call. And I don't think it depends on having SIPS either. If you used SIP, and got somebody different than you thought, then you wouldn't have the right keys to talk to them. But ZRTP is no good for having a secure conversation with somebody you don't have keys for, such as your bank, or anybody you are giving a credit card number to. 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 Sat May 27 02:18:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjs5O-00043X-Kb; Sat, 27 May 2006 02:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjs5M-0003y9-KW for sip@ietf.org; Sat, 27 May 2006 02:15:40 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjs5L-00083P-9K for sip@ietf.org; Sat, 27 May 2006 02:15:40 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 046BF1400D0; Sat, 27 May 2006 09:15:33 +0300 (EEST) Received: from rautu (allozyme189.gprs.dnafinland.fi [62.78.104.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id CBAA01400CA; Sat, 27 May 2006 09:15:25 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id D9295F03C1; Sat, 27 May 2006 09:15:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17527.61047.777277.88525@rautu.tutpro.com> Date: Sat, 27 May 2006 09:15:19 +0300 From: Juha Heinanen To: jbemmel@zonnet.nl Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? In-Reply-To: <1148674903.44776357ecd0e@webmail.versatel.nl> References: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> <1148674903.44776357ecd0e@webmail.versatel.nl> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "sip@ietf.org" , "ft@it.su.se" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org jbemmel@zonnet.nl writes: > Then how would they go about discovering a proxy that supports > outbound + SIPSEC? i cannot imagine a situation where my some of my domain's outbound proxies would support SIPSEC and some not. > As for the next version of the discovery draft: I think a section on > the requirements that we're trying to meet (and > also those that we're not) would be good. what outbound requirements we don't know about that would warrant delaying the document? -- 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 May 27 02:25:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjsD6-0000nz-UE; Sat, 27 May 2006 02:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjsD5-0000nu-Oe for sip@ietf.org; Sat, 27 May 2006 02:23:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjsD4-0008WI-Dy for sip@ietf.org; Sat, 27 May 2006 02:23:39 -0400 Received: by tutpro.com (Postfix, from userid 65534) id CC1F91400D0; Sat, 27 May 2006 09:23:37 +0300 (EEST) Received: from rautu (allozyme189.gprs.dnafinland.fi [62.78.104.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 99FA21400CA; Sat, 27 May 2006 09:23:31 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 38770F03C1; Sat, 27 May 2006 09:23:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17527.61542.179767.847622@rautu.tutpro.com> Date: Sat, 27 May 2006 09:23:34 +0300 From: Juha Heinanen To: Paul Kyzivat Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <44778963.9000102@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <44778963.9000102@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'Sip' , 'Dean Willis' , "'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 Paul Kyzivat writes: > But ZRTP is no good for having a secure conversation with somebody you > don't have keys for, such as your bank, or anybody you are giving a > credit card number to. bank or shop can very publish their key on their web site which i can add to my ssh known_hosts style list. -- 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 May 27 04:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjtqM-0003p0-D6; Sat, 27 May 2006 04:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjtqL-0003ou-Om for sip@ietf.org; Sat, 27 May 2006 04:08:17 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjtqK-0005ry-BG for sip@ietf.org; Sat, 27 May 2006 04:08:17 -0400 Received: (qmail 24096 invoked by uid 0); 27 May 2006 08:08:12 -0000 Received: from unknown (HELO webmail.zonnet.nl) ([10.170.1.95]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 May 2006 08:08:12 -0000 Received: by webmail.zonnet.nl (Postfix, from userid 33) id 4BAEFD32; Sat, 27 May 2006 10:08:15 +0200 (CEST) Received: from 81.59.178.113 ( [81.59.178.113]) as user jbemmel@localhost by webmail.versatel.nl with HTTP; Sat, 27 May 2006 10:08:15 +0200 Message-ID: <1148717295.447808ef3ad09@webmail.versatel.nl> Date: Sat, 27 May 2006 10:08:15 +0200 From: jbemmel@zonnet.nl To: Juha Heinanen Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? References: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> <1148674903.44776357ecd0e@webmail.versatel.nl> <17527.61047.777277.88525@rautu.tutpro.com> In-Reply-To: <17527.61047.777277.88525@rautu.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 81.59.178.113 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "sip@ietf.org" , "ft@it.su.se" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Citeren Juha Heinanen : > jbemmel@zonnet.nl writes: > > > Then how would they go about discovering a proxy that supports > > outbound + SIPSEC? > > i cannot imagine a situation where my some of my domain's outbound > proxies would support SIPSEC and some not. > Perhaps for the same reasons that some proxies would support outbound, and some not > > As for the next version of the discovery draft: I think a section on > > the requirements that we're trying to meet (and > > also those that we're not) would be good. > > what outbound requirements we don't know about that would warrant > delaying the document? For example: section 3.4 in ountbound-03 on edge proxies, do we need to support such a deployment? The current solution helps to locate the home registrar / proxy, but not edge proxies 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 Sat May 27 13:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2LK-0007iD-Dw; Sat, 27 May 2006 13:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2LI-0007g6-NK for sip@ietf.org; Sat, 27 May 2006 13:12:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk2LH-00056R-EK for sip@ietf.org; Sat, 27 May 2006 13:12:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 May 2006 10:12:47 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="284174147:sNHT34356348" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4RHCkKt004163; Sat, 27 May 2006 10:12:46 -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 k4RHCkCU021497; Sat, 27 May 2006 10:12:46 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4RH9cjw017498; Sat, 27 May 2006 10:09:39 -0700 Message-ID: <44788898.3060805@cisco.com> Date: Sat, 27 May 2006 10:12:56 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> <4477669E.4@cisco.com> <44776BF9.1070402@lucent.com> <44776CD3.1070500@cisco.com> <44776E85.2000800@lucent.com> In-Reply-To: <44776E85.2000800@lucent.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=1743; t=1148749966; x=1149613966; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=mat@cisco.com; z=From:Michael=20Thomas=20 |Subject:Re=3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DyzsSCxLWm96E0P7v4EIroZxlUvU=3D; b=SclTgWf3Iv3FoIET4m35R1ndeCYYRgV0vLPqtwLSsTX+L6T3PJ9pMMH2GkS//GNFRSll8Xeq wAhH5VX9Y9spZ+ZK5+Tgo/+YVLRLKtie2FDgsi6Rn6tq06xyRimjLesc; X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Vijay K. Gurbani wrote: > Michael Thomas wrote: > >>> >>> For this particular attack, [...] >> >> >> What particular attack? > > > The one you had replied to in my email ... let me see -- the > mail archive is not yet updated, so I will cut-and-paste > from your previous email: That's not what I'm asking for. I'm asking for a real life scenario that SIPS prevents a real life attack that cannot be thwarted with transport=tls. As far as I can tell, SIPS doesn't seem to be adding anything other than a hope and a prayer. Mike > > Michael Thomas wrote: > >> Vijay K. Gurbani wrote: >> >>> >>> So, P1 --> P2 --> P3 --> P4 is a set of proxies. P1 sends request >>> over TLS to P2. P2 lies and puts SIP/2.0/TLS in the Via header >>> that it inserts, but sends it to P3 over TCP. P3 accepts request >>> over TCP, notes that the topmost Via says TLS, but still continues >>> to process the request towards P4! It could of course, reject the >>> request right there, and thus stop this attack. For such a weak >>> link attack to succeed, both P2 and P3 will have to conspire (or P3 >>> would have to be a badly programmed proxy that does not know any >>> better). Collusions such as this across autonomous network >>> boundaries would be hard, I would think. Especially if the SIP >>> proxies at P2 and P3 were of different genealogies. >>> >> The more I think about this the more I do know what real life problem >> SIPS thinks it's solving. Can somebody be so kind as to tell me? Not >> what SIPS might provide, but what real life attacks it prevents that >> are uniquely due to SIPS (ie, different from transport=tls). >> >> Mike > > > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat May 27 13:22:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2SQ-0007eT-V7; Sat, 27 May 2006 13:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2SP-0007eN-A2 for sip@ietf.org; Sat, 27 May 2006 13:20:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk2SN-0005ng-SJ for sip@ietf.org; Sat, 27 May 2006 13:20:09 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 May 2006 10:20:07 -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/8.12.11) with ESMTP id k4RHK77J027409; Sat, 27 May 2006 10:20:07 -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 k4RHK7CU027411; Sat, 27 May 2006 10:20:07 -0700 (PDT) Received: from [192.168.0.100] (sjc-vpn6-64.cisco.com [10.21.120.64]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4RHGwVV017658; Sat, 27 May 2006 10:16:59 -0700 Message-ID: <44788A51.4060404@cisco.com> Date: Sat, 27 May 2006 10:20:17 -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] I-D ACTION:draft-ietf-sip-certs-00.txt References: <44776C2C.1030000@cisco.com> <5AC94CAD-9B95-4B5F-AE77-B8D6F295C4D3@cisco.com> In-Reply-To: <5AC94CAD-9B95-4B5F-AE77-B8D6F295C4D3@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=4722; t=1148750407; x=1149614407; c=relaxed/simple; s=sjdkim2001; 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]=20I-D=20ACTION=3Adraft-ietf-sip-certs-00.txt; X=v=3Dcisco.com=3B=20h=3D+TLPMZ9B0kn7euxzBt9oR0oDu2s=3D; b=YgMeRwHS+dBPoGZcZf+KO874nTv/jQX2GxyumfMahb0wUYhkECmgY1UN+H9BYgKc8v68BWOe acK/ofAF/d8J1a24ueSUAYf8sh93xUoK9bDiS29k9vNsx75coH/aXld4; X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > > Jon and I talked to the Security ADs and the various SIP and SIPPING > chairs to try and figure out best place for it. Clearly it needs > security review. There was no idea location but this seemed as good > as any. If this work has utility, I'd think that its utility would extend well beyond SIP. Conversely, if it's only useful for SIP, then there's probably something wrong. I was really serious that SIP really ought to be spawning new working groups with real charters. This looks like a perfect example of something that should be done on its own merits and with its own community of interested parties rather than yet another piece of work that has a barely tangential relationship to rendezvous protocols. Mike > > On May 26, 2006, at 1:59 PM, Michael Thomas wrote: > >> Do I undesrstand correctly that you want to store _private_ keys in >> this thing? Oi. >> >> Second, why is this being done in the SIP working group? It sure >> seems like it's >> out of the realm of this working group's expertise. See above. >> >> Mike >> >> 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 : Certificate Management Service for The Session >>> Initiation Protocol (SIP) >>> Author(s) : C. Jennings, et al. >>> Filename : draft-ietf-sip-certs-00.txt >>> Pages : 29 >>> Date : 2006-5-26 >>> >>> 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. 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-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-certs-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-certs-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 >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 27 19:40:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk8LD-0003g9-C5; Sat, 27 May 2006 19:37:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk8LC-0003g4-Ca for sip@ietf.org; Sat, 27 May 2006 19:37:06 -0400 Received: from celine.siteprotect.com ([64.41.122.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk8LB-0006t9-4g for sip@ietf.org; Sat, 27 May 2006 19:37:06 -0400 Received: from dimension.cornfed.com (pool-70-16-26-40.balt.east.verizon.net [70.16.26.40]) by celine.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4RNaos30154; Sat, 27 May 2006 18:36:50 -0500 Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips From: "Frank W. Miller" To: Juha Heinanen In-Reply-To: <17527.61542.179767.847622@rautu.tutpro.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <44778963.9000102@cisco.com> <17527.61542.179767.847622@rautu.tutpro.com> Content-Type: text/plain Organization: Cornfed Systems, LLC Date: Sat, 27 May 2006 19:36:48 -0400 Message-Id: <1148773008.2642.3.camel@dimension.cornfed.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'Sip' , Paul Kyzivat , "'Vijay K. Gurbani'" , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fwmiller@cornfed.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't think this is right. If I read the ZRTP draft correctly (and thats not a certainty), it generates keys dynamically, each side essentially creating a public key for the other end on demand. No key administration is required. FM On Sat, 2006-05-27 at 09:23 +0300, Juha Heinanen wrote: > Paul Kyzivat writes: > > > But ZRTP is no good for having a secure conversation with somebody you > > don't have keys for, such as your bank, or anybody you are giving a > > credit card number to. > > bank or shop can very publish their key on their web site which i can > add to my ssh known_hosts style list. > > -- 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 Sat May 27 22:58:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBQg-0008TQ-Qb; Sat, 27 May 2006 22:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBQf-0008TL-FH for sip@ietf.org; Sat, 27 May 2006 22:54:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkBQe-0004zB-4y for sip@ietf.org; Sat, 27 May 2006 22:54:57 -0400 Received: from [192.168.2.100] (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 k4S2u2MZ008300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 May 2006 21:56:03 -0500 Message-ID: <447911C5.7050805@softarmor.com> Date: Sat, 27 May 2006 21:58:13 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> In-Reply-To: <17527.12693.959315.99788@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: d6b246023072368de71562c0ab503126 Cc: 'Sip' , Paul Kyzivat , "'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 Juha Heinanen wrote: > Paul Kyzivat writes: > > > Its all based on trust in the proxies > > anyway, so why should we insist on TLS for *every* hop? > > i remember reading just last week than NSA is splitting fibers between > providers and capturing everything. sips MUST indicate to the end user > that TLS is used on EVERY hop. > Sine the proxies can tap the signal, what difference does it make? I don't trust the proxies. NSA will just "split" them too. We need something that's like TLS, end-to-end, or we don't have much of anything. And using that level of protection needs to be the norm, not the exception. -- 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 May 27 23:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBWJ-0003PW-1g; Sat, 27 May 2006 23:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBWG-00038o-Oi for sip@ietf.org; Sat, 27 May 2006 23:00:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkBWC-0005hH-Cx for sip@ietf.org; Sat, 27 May 2006 23:00:44 -0400 Received: from [192.168.2.100] (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 k4S31tkW008331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 May 2006 22:01:56 -0500 Message-ID: <44791326.4060905@softarmor.com> Date: Sat, 27 May 2006 22:04:06 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF09B97E61@zrc2hxm0.corp.nortel.com> <1148312948.13541.9.camel@niagra.pingtel.com> <4472002D.6070400@nokia.com> <44720282.8090705@cisco.com> <44721139.9020701@cisco.com> <17522.45483.589133.702489@rautu.tutpro.com> <1148493298.3423.4.camel@niagra.pingtel.com> <4474A09A.5030305@cisco.com> <4474AC6E.4000902@lucent.com> <17525.17186.384537.223811@rautu.tutpro.com> <4475FF64.4070403@lucent.com> <17526.463.76553.396380@rautu.tutpro.com> <447609C2.40109@lucent.com> <4476D578.8080608@nokia.com> <447714AC.5090401@lucent.com> <4477669E.4@cisco.com> <44776BF9.1070402@lucent.com> <44776CD3.1070500@cisco.com> <44776E85.2000800@lucent.com> <44788898.3060805@cisco.com> In-Reply-To: <44788898.3060805@cisco.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 , "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 Michael Thomas wrote: > That's not what I'm asking for. I'm asking for a real life scenario that > SIPS > prevents a real life attack that cannot be thwarted with transport=tls. > As far > as I can tell, SIPS doesn't seem to be adding anything other than a hope > and > a prayer. sips: reduces the probability of an accidental downgrade by intermediate proxies between the UAC and the proxy responsible for the AOR, if those proxies bother to honor it. As far as I can tell, that's all it does. -- 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 May 27 23:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBas-00075y-8o; Sat, 27 May 2006 23:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkBar-00075t-Fa for sip@ietf.org; Sat, 27 May 2006 23:05:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkBaq-0005oc-4q for sip@ietf.org; Sat, 27 May 2006 23:05:29 -0400 Received: from [192.168.2.100] (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 k4S36f6j008372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 May 2006 22:06:42 -0500 Message-ID: <44791444.1070109@softarmor.com> Date: Sat, 27 May 2006 22:08:52 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fwmiller@cornfed.com Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <44778963.9000102@cisco.com> <17527.61542.179767.847622@rautu.tutpro.com> <1148773008.2642.3.camel@dimension.cornfed.com> In-Reply-To: <1148773008.2642.3.camel@dimension.cornfed.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'Sip' , Juha Heinanen , "'Vijay K. Gurbani'" , 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 Frank W. Miller wrote: > I don't think this is right. If I read the ZRTP draft correctly (and > thats not a certainty), it generates keys dynamically, each side > essentially creating a public key for the other end on demand. No key > administration is required. The session key is constructed based on an exchange of public-key parts from each end. In that exchange, you get to see the "fingerprint" of your partner's key. You can validate this against a published fingerprint, if you have such available. If you don't, it works if you know the other party well enough to verify to your satisfaction that you have reached the correct party, and then go through the verbal fingerprint verification process. If you connect to a party you don't know well enough to identify, and you don't have a key for them, you can still do a verbal verification of the fingerprint to at least know that there's not a MITM. Of course, you still won't know who you're talking to. But at least next time, you'll know your talking to them again. -- 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 May 27 23:47:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkCDG-0005P5-8V; Sat, 27 May 2006 23:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkCDF-0005Ha-6p for sip@ietf.org; Sat, 27 May 2006 23:45:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkBZ2-0005lc-E0 for sip@ietf.org; Sat, 27 May 2006 23:03:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FkBLl-0004x4-3k for sip@ietf.org; Sat, 27 May 2006 22:49:55 -0400 Received: from [192.168.2.100] (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 k4S2p6HB008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 May 2006 21:51:07 -0500 Message-ID: <4479109D.2020900@softarmor.com> Date: Sat, 27 May 2006 21:53:17 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <072C5B76F7CEAB488172C6F64B30B5E301847CEE@xmb-rtp-20b.amer.cisco.com> <4475C295.6000605@lucent.com> <3C5FFAD6-3F03-41E7-BFD7-19823571F80C@softarmor.com> <44761B6C.9090500@lucent.com> <1148591688.44761e48e2a5f@webmail.versatel.nl> <447633B3.60307@cisco.com> <44767910.60303@lucent.com> In-Reply-To: <44767910.60303@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> While I agree in part, I don't think it is likely that many people >> will be making secure phone calls by typing in SIPSS or SIPSEC URIs. >> Most people don't type in HTTPS URIs either. Most of those are the >> result of link following. > > > I think your mileage may vary. I think what you say would > have been true a year or so ago. However, given that the media > has scared the public crazy about Internet security, chances are > fairly good that the average person not associated with the > IETF knows the difference between a http and a https URI. They > may not know what goes underneath the hood when they specify a https > URI, but they have come to associate https with trust that > they bestow when commencing on e-commerce and banking and > travel reservations, and getting their yearly credit report > free online, and what have you. I dunno. I just spent two weeks with my parents (they have DSL now, 85 miles from town in the middle of the desert) and upgraded my father's computer while I was there. They don't know the differentce between a URL and a search string (and frequently type the wrong one into the wrong entry field), never typed httpannything in their lives, and wouldn't know a lock icon if it bit them (and my father used to write 6803 machine code in his head -- without an assembler). A week after I had networked his shiny new PC, during which he had been using his browser nonstop, my father asked how to connect to the Internet from his new PC. He was shocked and dismayed to learn that he had been on the Internet all week. My mother, who has had a laptop with WiFi for two years and a dialup connection for five or six, still believes she is only connected "to the Internet" when she runs her Juno email client -- it is an abomination that runs IE "in a frame". At the other extreme, I almost always type https:, and if it doesn't work, I curse a few times, and then decide whether I'm going to risk http. -- 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 May 28 02:03:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkEJg-0007Zt-5Y; Sun, 28 May 2006 01:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkEJe-0007XJ-1a for sip@ietf.org; Sun, 28 May 2006 01:59:54 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkEJa-0006kk-KZ for sip@ietf.org; Sun, 28 May 2006 01:59:54 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 08EDF14001C; Sun, 28 May 2006 08:59:45 +0300 (EEST) Received: from rautu (allozyme249.gprs.dnafinland.fi [62.78.104.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4C9BD13FFE2; Sun, 28 May 2006 08:59:36 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id A4C80F03C1; Sun, 28 May 2006 08:59:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17529.15428.268933.754274@rautu.tutpro.com> Date: Sun, 28 May 2006 08:59:32 +0300 From: Juha Heinanen To: fwmiller@cornfed.com Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <1148773008.2642.3.camel@dimension.cornfed.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <44778963.9000102@cisco.com> <17527.61542.179767.847622@rautu.tutpro.com> <1148773008.2642.3.camel@dimension.cornfed.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'Sip' , Paul Kyzivat , "'Vijay K. Gurbani'" , '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 Frank W. Miller writes: > I don't think this is right. If I read the ZRTP draft correctly (and > thats not a certainty), it generates keys dynamically, each side > essentially creating a public key for the other end on demand. No key > administration is required. the page says somewhere that it operates similarly to ssh. ssh also generates keys dynamically and no admin is needed, but when you connect to a new party, ssh client asks if you want to trust the key of the other party and if so it adds it to your known_hosts file. if you already have key of the other party in your known_hosts file, ssh client warns you if the key of the other party does not match the one you have in file. -- 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 Sun May 28 02:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkEMf-0000Pw-CE; Sun, 28 May 2006 02:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkEMd-0000Pr-Ei for sip@ietf.org; Sun, 28 May 2006 02:02:59 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkEMc-0006sl-3u for sip@ietf.org; Sun, 28 May 2006 02:02:59 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 8394313F8A6; Sun, 28 May 2006 09:02:57 +0300 (EEST) Received: from rautu (allozyme249.gprs.dnafinland.fi [62.78.104.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id C8D5113F739; Sun, 28 May 2006 09:02:50 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 5D676F03C1; Sun, 28 May 2006 09:02:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17529.15626.334110.853151@rautu.tutpro.com> Date: Sun, 28 May 2006 09:02:50 +0300 From: Juha Heinanen To: Dean Willis Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <447911C5.7050805@softarmor.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <447911C5.7050805@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'Sip' , Paul Kyzivat , "'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 Dean Willis writes: > Sine the proxies can tap the signal, what difference does it make? i don't disagree with you that end-to-end TLS would be a good thing. but it does make a difference if NSA needs to get to operators computer, because then they need physical access to operators computer room, which is difficult to do unnoticed. -- 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 Sun May 28 18:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkTgf-0006d0-UW; Sun, 28 May 2006 18:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkTge-0006cv-Nl for sip@ietf.org; Sun, 28 May 2006 18:24:40 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkTgd-0006dV-GY for sip@ietf.org; Sun, 28 May 2006 18:24:40 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2C7536C017 for ; Sun, 28 May 2006 18:24:35 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: <17500.61784.185527.783328@rautu.tutpro.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> <17500.61784.185527.783328@rautu.tutpro.com> Content-Type: text/plain Date: Sun, 28 May 2006 18:24:35 -0400 Message-Id: <1148855075.28687.39.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Sip] Primary vs. backup X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Reading draft-ietf-sip-outbound-03, I see that it mentions configuring a UA with a "primary" and a "backup" proxy, and assumes that the UA will maintain connections with both of them, preferentially using the "primary" for outgoing messages. But as I read it, that is entirely a suggestion -- implicitly, the authors expect that the reader understands that since the I-D does not specify how the configuration is done, and since the two connections are equivalent in outcome (if not performance), the number of proxies configured and the algorithm which the UA uses choose which proxies to contact and use is a matter of UA policy, outside the scope of the I-D. Reading draft-koivusalo-sip-outbound-discovery-00, it appears that it is formalizing the classes of "primary" and "backup" proxies, and requiring that the UA maintain a connection to exactly one of each. Or rather, each SRV priority level defines a class of servers, and the UA must maintain a connection to exactly one of each. It seems to me to be excessively restrictive to constrain UAs to this scheme, given that we have little experience with this problem, and that this scheme is quite different than the behavior previously specified by a set of SRV records. Unfortunately, we really do need to solve the problem of locating Outbound-capable servers using DNS records. But do we need to specify exactly which servers a UA must use, beyond the rather general preference and balancing rules of RFC 3263? At this point, an idea occurs to me that must have already been considered and rejected -- Why not have the UA attempt to register using the 3263 rules, but specifying "Requires: outbound"? That will automatically exclude servers that do not support Outbound. The only limitation would be that a UA using Outbound would see the same priority relationships between the servers that a non-Outbound UA would see. 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 May 28 21:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkWU5-00081Y-Kf; Sun, 28 May 2006 21:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkWU4-00081S-Bl for sip@ietf.org; Sun, 28 May 2006 21:23:52 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkWU3-0007Ga-2z for sip@ietf.org; Sun, 28 May 2006 21:23:52 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 590B86C017 for ; Sun, 28 May 2006 21:23:46 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: References: Content-Type: text/plain Date: Sun, 28 May 2006 21:23:46 -0400 Message-Id: <1148865826.28687.53.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Sip] Comments on draft-ietf-sip-outbound-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 Section 1: Introduction Since, such detection takes time and leaves a window of opportunity ... should be Since such detection takes time and leaves a window of opportunity ... Section 4.2.1: Registration by Other Instances A User Agent MUST NOT include an instance-id or reg-id in the Contact header field of a registration if the registering UA is not the same instance as the UA referred to by the target Contact header field. (This practice is occasionally used to install forwarding policy into registrars.) This seems overly restrictive. In regard to instance-id, it makes it impossible for a compliant UA to do a third-party registration that obtains a GRUU, even if the UA has no intentions of using the flow mechanism in regard to requests to/from the Contact UA. ISTM that there should be no restriction on using instance-id independently of Outbound. In regard to reg-id, this restriction would make it difficult for an edge-proxy to open a flow to a registrar/proxy to provide service for a UA in some cases, because the edge-proxy could not perform a third-party registration of the UA. (Although it could forge a first-party registration to the same effect.) Section 5.3: Forwarding Requests Note that techniques to ensure that mid-dialog requests are routed over an existing flow are out of scope and therefore not part of this specification. However, an approach such as having the Edge Proxy Record-Route with a flow token is one way to ensure that mid-dialog requests are routed over the correct flow. ISTM that to achieve the goals of this I-D, it is vital for mid-dialog requests to be routed over an existing flow. But this paragraph is not clear as to whether the I-D specifies that "techniques" MUST be used (but is not specifying what ones are to be used) or just noting that it's possible to do so. Section 7: Mechanisms for All Servers (Proxys, Registars, UAS) A SIP device that receives SIP messages directly from a UA needs to behave as specified in this section. Such devices would generally include a Registrar and an Edge Proxy, as they both receive register requests directly from a UA. This should be tightened up, as *any* SIP device can receive SIP messages directly from a UA. Also, this paragraph does not use the BCP 14 key words. Section 8: Example Message Flow In this message flow, there are three REGISTERs: F1, F3, and F15. F1 and F3, which create flows to two different registrars, have different Call-Ids, which makes sense. But the I-D says that F15 has a different Call-Id than F1, despite being a REGISTER to the same proxy, for the same flow, albeit after the proxy rebooted. It seems to me that F15 should be a successor to F1, with the same Call-Id and higher CSeq, as F15 is meant to refresh or replace F1. 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 May 28 22:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkX3M-0005hq-Dr; Sun, 28 May 2006 22:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkX30-0004Yu-2E for sip@ietf.org; Sun, 28 May 2006 21:59:58 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkWpF-0001u7-NS for sip@ietf.org; Sun, 28 May 2006 21:45:46 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 76ABF6C017 for ; Sun, 28 May 2006 21:45:41 -0400 (EDT) Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix-01 : deprecate spiralling for forking proxies From: "Dale R. Worley" To: Sip In-Reply-To: <001201c6790e$f7547c10$31713b51@BEMBUSTER> References: <001201c6790e$f7547c10$31713b51@BEMBUSTER> Content-Type: text/plain Date: Sun, 28 May 2006 21:45:41 -0400 Message-Id: <1148867141.28687.65.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2006-05-16 at 19:34 +0200, Jeroen van Bemmel wrote: > Consider the following alternative as a solution to the exponential > message problem: deprecate spiralling for forking proxies That's probably not a good idea. We see quite a lot of instances where requests spiral, sometimes intermixed with forking. But I don't think the computational load is as high as people imagine. First off, everybody agrees that the load for processing one passage of any particular message is o(N), where N is the number of Via's in the message. But processing a SIP message is already o(N), because its bytes have to be copied. So the asymptotic behavior is no worse than it is now. The second question is how big is the constant, how much work does it take to compute the digest? The digest doesn't have to be cryptographic, because it is assumed that nobody in the loop path from the proxy to itself is rewriting the digests. (If a malicious agent was in the loop, it would be suffering from exponential load, too.) So the digest can be a simple hash, which is as fast to compute as any ordinary string operation. Of course it is not a unique encoding of the control fields of the message, but that's OK, since one can append the control fields themselves, or append a pointer to the proxy's internal record of the transaction for the transit of the message, to check in the rare cases where the hash collides. 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 May 29 01:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fka5v-0001kB-4d; Mon, 29 May 2006 01:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fka5t-0001il-Bb for sip@ietf.org; Mon, 29 May 2006 01:15:09 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fka5q-0006DX-Vb for sip@ietf.org; Mon, 29 May 2006 01:15:09 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 9118E13F98D; Mon, 29 May 2006 08:15:01 +0300 (EEST) Received: from rautu (guanine210.gprs.dnafinland.fi [62.78.120.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 5DFD713F97F; Mon, 29 May 2006 08:14:54 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 85CB3F03C1; Mon, 29 May 2006 08:14:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17530.33607.493642.294594@rautu.tutpro.com> Date: Mon, 29 May 2006 08:14:47 +0300 From: Juha Heinanen To: "Dale R. Worley" Subject: [Sip] Primary vs. backup In-Reply-To: <1148855075.28687.39.camel@niagra.pingtel.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> <17500.61784.185527.783328@rautu.tutpro.com> <1148855075.28687.39.camel@niagra.pingtel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Dale R. Worley writes: > Unfortunately, we really do need to solve the problem of locating > Outbound-capable servers using DNS records. But do we need to specify > exactly which servers a UA must use, beyond the rather general > preference and balancing rules of RFC 3263? dale, this is exactly what i have proposed in two or three emails to this list already. since i don't remember anyone opposing, it would be nice if the authors outbound would issue a new version where the primary/backup distinction has been eliminated. > At this point, an idea occurs to me that must have already been > considered and rejected -- Why not have the UA attempt to register > using the 3263 rules, but specifying "Requires: outbound"? That will > automatically exclude servers that do not support Outbound. > The only limitation would be that a UA using Outbound would see the same > priority relationships between the servers that a non-Outbound UA > would see. yes, it would mean lots of redirects by the proxies. -- 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 May 29 02:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbWF-0008Ts-4B; Mon, 29 May 2006 02:46:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbWD-0008Sm-Kt for sip@ietf.org; Mon, 29 May 2006 02:46:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkbJ7-0005a8-RU for sip@ietf.org; Mon, 29 May 2006 02:33:04 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 111804F0001; Mon, 29 May 2006 08:32:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 08:32:44 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 08:32:44 +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] Primary vs. backup Date: Mon, 29 May 2006 08:32:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Primary vs. backup Thread-Index: AcaC33EBgXWGhJpXRA2DBbukcwtgeAACVYiA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Dale R. Worley" X-OriginalArrivalTime: 29 May 2006 06:32:44.0240 (UTC) FILETIME=[B16DED00:01C682E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Unfortunately, we really do need to solve the problem of locating =20 >>Outbound-capable servers using DNS records. But do we need to specify >>exactly which servers a UA must use, beyond the rather general =20 >>preference and balancing rules of RFC 3263? >dale, this is exactly what i have proposed in two or three emails to this list already. since i don't remember anyone opposing, it would be nice if the=20 >authors outbound would issue a new version where the primary/backup distinction has been eliminated. [CHH] This may be related to the discussion we had a while ago (thread subject: "Outbound: Multiple flows and forking"). At that time I proposed text saying "For reliability or load balancing reasons, the UA MAY send REGISTER to more than one outbound proxy...". At that point we also discussed whehter "primary and secondary" is the correct wording in the first place. [/CHH] >>At this point, an idea occurs to me that must have already been > considered and rejected -- Why not have the UA attempt to register =20 >>using the 3263 rules, but specifying "Requires: outbound"? That will > automatically exclude servers that do not support Outbound. >>The only limitation would be that a UA using Outbound would see the same > priority relationships between the servers that a non-Outbound UA =20 >>would see. >yes, it would mean lots of redirects by the proxies. [CHH] I think that depends pretty much on how the operators build and design their networks. [/CHH] 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@cFrom sip-bounces@ietf.org Mon May 29 02:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbWF-0008Ts-4B; Mon, 29 May 2006 02:46:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbWD-0008Sm-Kt for sip@ietf.org; Mon, 29 May 2006 02:46:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkbJ7-0005a8-RU for sip@ietf.org; Mon, 29 May 2006 02:33:04 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 111804F0001; Mon, 29 May 2006 08:32:45 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 08:32:44 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 08:32:44 +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] Primary vs. backup Date: Mon, 29 May 2006 08:32:43 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Primary vs. backup Thread-Index: AcaC33EBgXWGhJpXRA2DBbukcwtgeAACVYiA From: "Christer Holmberg \(JO/LMF\)" To: "Juha Heinanen" , "Dale R. Worley" X-OriginalArrivalTime: 29 May 2006 06:32:44.0240 (UTC) FILETIME=[B16DED00:01C682E9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Unfortunately, we really do need to solve the problem of locating =20 >>Outbound-capable servers using DNS records. But do we need to specify >>exactly which servers a UA must use, beyond the rather general =20 >>preference and balancing rules of RFC 3263? >dale, this is exactly what i have proposed in two or three emails to this list already. since i don't remember anyone opposing, it would be nice if the=20 >authors outbound would issue a new version where the primary/backup distinction has been eliminated. [CHH] This may be related to the discussion we had a while ago (thread subject: "Outbound: Multiple flows and forking"). At that time I proposed text saying "For reliability or load balancing reasons, the UA MAY send REGISTER to more than one outbound proxy...". At that point we also discussed whehter "primary and secondary" is the correct wording in the first place. [/CHH] >>At this point, an idea occurs to me that must have already been > considered and rejected -- Why not have the UA attempt to register =20 >>using the 3263 rules, but specifying "Requires: outbound"? That will > automatically exclude servers that do not support Outbound. >>The only limitation would be that a UA using Outbound would see the same > priority relationships between the servers that a non-Outbound UA =20 >>would see. >yes, it would mean lots of redirects by the proxies. [CHH] I think that depends pretty much on how the operators build and design their networks. [/CHH] 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 May 29 02:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbVq-00083Q-5v; Mon, 29 May 2006 02:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbVp-0007zq-6N for sip@ietf.org; Mon, 29 May 2006 02:46:01 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkbT0-0006wa-9W for sip@ietf.org; Mon, 29 May 2006 02:43:08 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 0F18613FD93; Mon, 29 May 2006 09:43:00 +0300 (EEST) Received: from rautu (guanine210.gprs.dnafinland.fi [62.78.120.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 46C2F13F98D; Mon, 29 May 2006 09:42:50 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id DF132F03C1; Mon, 29 May 2006 09:42:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17530.38885.438515.677118@rautu.tutpro.com> Date: Mon, 29 May 2006 09:42:45 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Primary vs. backup In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Christer Holmberg (JO/LMF) writes: > [CHH] I think that depends pretty much on how the operators build and > design their networks. [/CHH] the idea is that local clients use outbound proxies and others would use non-outbound proxies. you can play with probabilities and DNS record priorities, but if about half of request come from local clients and half from non-local sources, i don't see how you can avoid about 50 % of request initially ending up to wrong 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 s.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 May 29 02:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbVq-00083Q-5v; Mon, 29 May 2006 02:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbVp-0007zq-6N for sip@ietf.org; Mon, 29 May 2006 02:46:01 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkbT0-0006wa-9W for sip@ietf.org; Mon, 29 May 2006 02:43:08 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 0F18613FD93; Mon, 29 May 2006 09:43:00 +0300 (EEST) Received: from rautu (guanine210.gprs.dnafinland.fi [62.78.120.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 46C2F13F98D; Mon, 29 May 2006 09:42:50 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id DF132F03C1; Mon, 29 May 2006 09:42:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17530.38885.438515.677118@rautu.tutpro.com> Date: Mon, 29 May 2006 09:42:45 +0300 From: Juha Heinanen To: "Christer Holmberg (JO/LMF)" Subject: RE: [Sip] Primary vs. backup In-Reply-To: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> References: <5EB80D22825EEE42872083AD5BFFB594017F0F9F@esealmw113.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Christer Holmberg (JO/LMF) writes: > [CHH] I think that depends pretty much on how the operators build and > design their networks. [/CHH] the idea is that local clients use outbound proxies and others would use non-outbound proxies. you can play with probabilities and DNS record priorities, but if about half of request come from local clients and half from non-local sources, i don't see how you can avoid about 50 % of request initially ending up to wrong 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 Mon May 29 02:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbWt-0000HG-QT; Mon, 29 May 2006 02:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkbVv-0008M5-JM for sip@ietf.org; Mon, 29 May 2006 02:46:07 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkbQH-0006SP-PN for sip@ietf.org; Mon, 29 May 2006 02:40:21 -0400 Received: (qmail 23873 invoked by uid 0); 29 May 2006 06:40:09 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 May 2006 06:40:09 -0000 Message-ID: <004601c682ea$b9390dc0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Dale R. Worley" , "Sip" References: <001201c6790e$f7547c10$31713b51@BEMBUSTER> <1148867141.28687.65.camel@niagra.pingtel.com> Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix-01 : deprecate spirallingfor forking proxies Date: Mon, 29 May 2006 08: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.2869 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 Dale, > On Tue, 2006-05-16 at 19:34 +0200, Jeroen van Bemmel wrote: >> Consider the following alternative as a solution to the exponential >> message problem: deprecate spiralling for forking proxies > > That's probably not a good idea. We see quite a lot of instances where > requests spiral, sometimes intermixed with forking. > Such legitimate cases, if they exist, could be converted into non-spirals by using either one of DNS aliases, additional IP addresses per interface, or separate ports for the first, second and in general Nth pass > But I don't think the computational load is as high as people imagine. > First off, everybody agrees that the load for processing one passage of > any particular message is o(N), where N is the number of Via's in the > message. But processing a SIP message is already o(N), because its > bytes have to be copied. So the asymptotic behavior is no worse than it > is now. > I agree, and others have also pointed out that N tends to be small in practice. > The second question is how big is the constant, how much work does it > take to compute the digest? The digest doesn't have to be > cryptographic, because it is assumed that nobody in the loop path from > the proxy to itself is rewriting the digests. (If a malicious agent was > in the loop, it would be suffering from exponential load, too.) So the > digest can be a simple hash, which is as fast to compute as any ordinary > string operation. Of course it is not a unique encoding of the control > fields of the message, but that's OK, since one can append the control > fields themselves, or append a pointer to the proxy's internal record of > the transaction for the transit of the message, to check in the rare > cases where the hash collides. > You can make the hash collission arbitrarily unlikely by increasing the number of bits in the hash. You already have a pointer to the proxy's internal record (Via branch id of the previous iteration) but that does not work for stateless proxies But since you're pointing it out: for a forking proxy, which by definition must be stateful, it could be specified that when forking it needs to go and check any previous record it has of the transaction: iterate over the via headers, when found lookup the transaction using that via's branch, and compare the set of fields that are supposed to show some change > 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 May 29 03:07:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkbp1-0006FO-9w; Mon, 29 May 2006 03:05:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkboz-0006FJ-RG for sip@ietf.org; Mon, 29 May 2006 03:05:49 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkbow-0001eF-AE for sip@ietf.org; Mon, 29 May 2006 03:05:49 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T75duj021749; Mon, 29 May 2006 10:05:42 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:05:42 +0300 Received: from [172.21.38.161] ([172.21.38.161]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 May 2006 10:05:42 +0300 Message-ID: <447A9D45.6090002@nokia.com> Date: Mon, 29 May 2006 10:05:41 +0300 From: Aki Niemi User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: ext Gonzalo Camarillo Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> <8C7CAACA-4217-4B5B-9078-B07BBD6F6123@cisco.com> <4476FBFD.8010508@ericsson.com> In-Reply-To: <4476FBFD.8010508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2006 07:05:42.0171 (UTC) FILETIME=[4C5E3EB0:01C682EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Cullen Jennings , SIP IETF , 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 Gonzalo Camarillo wrote: > Hi, > > the conclusion was the IETF wanted to have tighter control on SIP URI > parameters than on header field parameters. Therefore, one would need a > standards-track RFC in order to create new SIP URI parameters... that > was the intent. Believing this gives the WG tighter control is a delusion. Similarly, one could set the speedlimit on highways to 2 miles or 5 kilometers an hour, and sit and watch everyone breaking it. I think all this does is it makes people who need URI parameters go underground. And that makes interop worse, not better. It also all but guarantees the SIP* working groups will be flooded with trivial specifications of extension parameters, over which we will be able to have many entertaining but utterly useless debates. I'll also note that in the end, the only people who will even attempt to abide by these types of policies are other SDOs because they sort of have to; everyone else in the industry won't pay any attention. I was of the opinion way back when this was discussed the last time, but remember being in the minority. 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 May 29 03:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcPr-0001SF-TQ; Mon, 29 May 2006 03:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcPq-0001S9-HS for sip@ietf.org; Mon, 29 May 2006 03:43:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkcPo-0004ZE-VE for sip@ietf.org; Mon, 29 May 2006 03:43:54 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T7hodZ016645; Mon, 29 May 2006 10:43:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:43:50 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:43:50 +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] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Mon, 29 May 2006 10:43:49 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F025D63EE@esebe103.NOE.Nokia.com> In-Reply-To: <1148674903.44776357ecd0e@webmail.versatel.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Thread-Index: AcaBAgkPN+HWrDS6Rt6ifwG0DROCLQB7orpg From: To: X-OriginalArrivalTime: 29 May 2006 07:43:50.0204 (UTC) FILETIME=[A0245FC0:01C682F3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >In other words, you agree with what I say above, but stipulate=20 >that until outbound there was no real need for it either.=20 You have understood me more or less correctly. >So then the question is: is there a need for something=20 >generic, or will something that only works for=20 >outbound suffice?=20 I would also prefer to have a generic solution if it would be readily available. However that does not seem to be the case. DNS TXT records appear to be even too generic while new service types for NAPTR records limited to scale the solution towards any new combination of services. Promoting the NAPTR technique would rely on the assumption of that another technique would probably have to be used to solve=20 any similar problems in the future. >I can think of several SIP features that could benefit from a=20 >discovery capability: SIP Identity, SIP Privacy=20 >(RFC3323), Security Mechanism agreement (RFC3329) to name a=20 >few (and perhaps proxies that will support=20 >the new to-be-defined SIPS security model).=20 However I restate my opinion that SIP Outbound is a problem with an exceptional significance. While the features you mentioned above would benefit from a discovery capability, SIP Outbound has a few properties that make the discovery capability essential: - It is practically a precondition for a UA to use SIP at all in the environments where UA is behind a NAT. In those cases the UA could not just opt using the proxy it discovers even if it would not support SIP Outbound. - For reliability point of view SIP Outbound suggests the UA to set up two different flows towards two different proxies,=20 which makes the discovery problem even more complex. - SIP Outbound relies on multiplexing SIP and STUN protocols to the same port, which in my opinion is really a new type of service, rather than an extension to an existing protocol. >I don't have the solution, but my gut feeling is that neither=20 >NAPTR SIP-O nor TXT records will do us much good in=20 >the long run. Ultimately we will need a SIP-based mechanism here. Relying on SIP based mechanisms has a few problems: 1. It would introduce extra round-trips as the UA would need to blindly try if the proxy found by RFC 3263 rules would support SIP Outbound or not. If not, then the number of further round- trips would depend on whether the contacted proxy is able or is not able to redirect the UA towards another proxy. 2. If the UA aims to set up two flows towards two different proxies, it would make the round-trips easily to double. Furthermore I can not imagine how the proxies could make sure that they would not=20 redirect the second flow towards the very same proxy with which the UA already has set up the first flow. >As for the next version of the discovery draft: I think a=20 >section on the requirements that we're trying to meet (and=20 >also those that we're not) would be good.=20 I agree this would be a good idea, based on the various comments given to the first version of the I-D on this mailing list. I try to elaborate the reqs for the next version. Regards, Erkki=20 >-----Original Message----- >From: ext jbemmel@zonnet.nl [mailto:jbemmel@zonnet.nl]=20 >Sent: 26.May.2006 23:22 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: ft@it.su.se; sip@ietf.org >Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to=20 >rely on NAPTR orTXT records ? > >Hi Erkki, >>=20 >> What comes to the approach to use DNS for automatically discovering >> the proxies supporting SIP Outbound: >>=20 >> >One thing to note here is that current clients in general=20 >> >don't have a way to lookup or prefer proxies with specific=20 >features.=20 >>=20 >> I would challenge this by claiming that before=20 >draft-ietf-sip-outbound >> the clients did not have any strong reason to do so. But my opinion=20 >> is that the strong reason has emerged with SIP Outbound, which is >> essential to enable the UA to traverse NAT to use any feature of SIP. >>=20 > >In other words, you agree with what I say above, but stipulate=20 >that until outbound there was no real need for it=20 >either. So then the question is: is there a need for something=20 >generic, or will something that only works for=20 >outbound suffice?=20 > >I can think of several SIP features that could benefit from a=20 >discovery capability: SIP Identity, SIP Privacy=20 >(RFC3323), Security Mechanism agreement (RFC3329) to name a=20 >few (and perhaps proxies that will support=20 >the new to-be-defined SIPS security model).=20 > >I understand Juha when he says "focus on outbound + discovery=20 >now". On the other hand, from the discussion=20 >so far I also sense that we haven't got all the requirements=20 >clear yet. My fear is that we'll end up with something=20 >that sort of works for outbound, but breaks as soon as we=20 >stumble upon a next 'discontinuity point' (say,=20 >SIPSEC) that UACs also consider as 'critical'. Then how would=20 >they go about discovering a proxy that supports=20 >outbound + SIPSEC? > >I don't have the solution, but my gut feeling is that neither=20 >NAPTR SIP-O nor TXT records will do us much good in=20 >the long run. Ultimately we will need a SIP-based mechanism here. > >As for the next version of the discovery draft: I think a=20 >section on the requirements that we're trying to meet (and=20 >also those that we're not) would be good.=20 > >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 May 29 04:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcnq-00055V-B5; Mon, 29 May 2006 04:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcno-00055K-Rg for sip@ietf.org; Mon, 29 May 2006 04:08:40 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkcnn-0007rY-HB for sip@ietf.org; Mon, 29 May 2006 04:08:40 -0400 Received: from [192.168.2.107] (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 k4T89sFB001582 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 May 2006 03:09:54 -0500 From: Dean Willis To: sip@ietf.org Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 29 May 2006 03:22:39 -0500 User-Agent: KMail/1.8.3 References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> In-Reply-To: <17529.15626.334110.853151@rautu.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605290322.40468.dean.willis@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Juha Heinanen , "'Vijay K. Gurbani'" , 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 Sunday 28 May 2006 01:02, Juha Heinanen wrote: > Dean Willis writes: > > Sine the proxies can tap the signal, what difference does it make? > > i don't disagree with you that end-to-end TLS would be a good thing. > but it does make a difference if NSA needs to get to operators computer, > because then they need physical access to operators computer room, which > is difficult to do unnoticed. Nah, they just tell the operator to give them root access on all proxies, then make their tap. What operator (besides maybe Qwest, of whom I am currently very proud) would say no? Or more likely, they tell the proxy makers to leave them a back door, so they can tap the proxies without even asking permission. I'm sure stuff like this happens, if not with the NSA, then with some other agency in some country or another. -- 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 May 29 04:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkd9f-0000rZ-Q6; Mon, 29 May 2006 04:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkd9e-0000mO-37 for sip@ietf.org; Mon, 29 May 2006 04:31:14 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkd9d-0001Ha-Dv for sip@ietf.org; Mon, 29 May 2006 04:31:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T8V9kj031482; Mon, 29 May 2006 11:31:12 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 11:31:07 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 11:31:06 +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] Primary vs. backup Date: Mon, 29 May 2006 11:31:06 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F025D64A2@esebe103.NOE.Nokia.com> In-Reply-To: <1148855075.28687.39.camel@niagra.pingtel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Primary vs. backup Thread-Index: AcaCpnqSv+hlbSpAQQSVqfpN2QP2FQATUsxg From: To: , X-OriginalArrivalTime: 29 May 2006 08:31:06.0944 (UTC) FILETIME=[3AF88C00:01C682FA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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, Thanks Dale for the attention you have given to the sip-outbound-discovery draft. I try to provide some insight of the aims of the draft, rationale for the=20 choices made in that draft and a briefing of changes=20 I am planning to do into its next version: >Reading draft-ietf-sip-outbound-03, I see that it mentions configuring >a UA with a "primary" and a "backup" proxy, and assumes that the UA >will maintain connections with both of them, preferentially using the >"primary" for outgoing messages. > >But as I read it, that is entirely a suggestion -- implicitly, the >authors expect that the reader understands that since the I-D does not >specify how the configuration is done, and since the two connections >are equivalent in outcome (if not performance), the number of proxies >configured and the algorithm which the UA uses choose which proxies to >contact and use is a matter of UA policy, outside the scope of the >I-D. Yes and no. Outbound-03 introduces a number of example configurations, some with and others without the support for backup connection. However the normative text in section 4.2 currently tells: A UA MUST support sets with at least two outbound proxy URIs (primary and backup) and SHOULD support sets with up to four URIs. For each outbound proxy URI in the set, the UA MUST send a REGISTER in the normal way using this URI as the default outbound proxy. However section 4.2 also leaves the door open to use other means than configuration, e.g. DNS: UAs are configured with one or more SIP URIs representing the default outbound-proxy-set. The specification assumes the set is determined via configuration but future specifications may define other mechanisms such as using DNS to discover this set.=20 What I have been trying to do is to formalise those mechanisms based=20 on DNS in order to: 1. Make it possible to implement UAs that would support two flows towards two proxies even if the UA is configured with 0-1 URIs based on which the UA tries to locate the proxy: a) UA tries to locate its home proxies based on the domain=20 of the AOR of the user b) UA tries to locate a visited proxy based on DHCP query which results a single domain name to be used 2. Make it more specific how the service provider should configure DNS so that compliant UAs would be able to find two different proxies to contact with. The aim is to define the algorithm that the UA uses for discovery so that the service provider could achieve various aims like: - Only a single proxy, no support for backup flows - One pool of proxies amongst which the UA can select two for setting up the flows towards them. Server load balancing would be done within this pool. - Separate pools of proxies for primary flows (load balancing amongst them) and redundant idle proxies for backup flows. The sizes of those pools can be same or different, e.g. to allow N primary proxies to be protected by one backup proxy. I am planning to publish a revised scheme of using SRV records to support these items, based on the comments I have got for sip-outbound-discovery-00. Also I have agreed to add a requirements section to the draft to make those aims clearer. >Reading draft-koivusalo-sip-outbound-discovery-00, it appears that it >is formalizing the classes of "primary" and "backup" proxies, and >requiring that the UA maintain a connection to exactly one of each. In the next version I will change the point of view to be the view of the UA. So instead of discussing primary and backup proxies, the I-D will rather describe how a UA will set up its primary and backup flow towards two different proxies. The proxies themselves will not have a fixed "primary" and "backup" status, at least in all the cases. >Or rather, each SRV priority level defines a class of servers, and the >UA must maintain a connection to exactly one of each. It seems to me >to be excessively restrictive to constrain UAs to this scheme, given >that we have little experience with this problem, and that this scheme >is quite different than the behavior previously specified by a set of >SRV records. Please note that this spec would not prevent developing UAs which=20 support a larger numer of proxies by configuration. The target of this I-D is just to make it possible to develope UAs that need=20 only a single URI to be configured (e.g. AOR) and automatically=20 discover the used proxies based on a standardized scheme of DNS=20 configuration. Next version will actually use exactly the same algorithm for=20 handling the SRV records as already specified in RFC 2782. The new idea is just to use a reduced set of SRV records to be sorted for setting up the backup flow. But what will remain is the formal idea of how a UA can automatically discover two different proxies (supporting SIP Outbound) so that it can set up exactly two flows (primary and backup) towards them. Also it should be possible to have a mobile type of UA that only sets up one single flow, so that it would not exhaust its battery too quickly for keepalives. >Unfortunately, we really do need to solve the problem of locating >Outbound-capable servers using DNS records. But do we need to specify >exactly which servers a UA must use, beyond the rather general >preference and balancing rules of RFC 3263? The problem is that those rules you are referring to do not give any guideline for selecting a proxy for the backup flow. This is=20 one of the two major problems my I-D is trying to solve. (The other problem is how to find which proxies support SIP Outbound as the domain might have proxies without that support, too.) >At this point, an idea occurs to me that must have already been >considered and rejected -- Why not have the UA attempt to register >using the 3263 rules, but specifying "Requires: outbound"? That will >automatically exclude servers that do not support Outbound. The only >limitation would be that a UA using Outbound would see the same >priority relationships between the servers that a non-Outbound UA >would see. Relying on SIP based mechanisms has a few problems: 1. It would introduce extra round-trips as the UA would need to blindly try if the proxy found by RFC 3263 rules would support SIP Outbound or not. If not, then the number of further round- trips would depend on whether the contacted proxy is able or is not able to redirect the UA towards another proxy. 2. If the UA aims to set up two flows towards two different proxies, it would make the round-trips easily to double. Furthermore I can not imagine how the proxies could make sure that they would not=20 redirect the second flow towards the very same proxy with which the UA already has set up the first flow. I hope to be able to publish the next version of sip-outbound-discovery still this week. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 29 05:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkeEe-0000pj-5F; Mon, 29 May 2006 05:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkeEc-0000pe-9d for sip@ietf.org; Mon, 29 May 2006 05:40:26 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkeEZ-00082A-QU for sip@ietf.org; Mon, 29 May 2006 05:40:26 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4T9eKU2020617; Mon, 29 May 2006 12:40:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 12:40:22 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 12:40:21 +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] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Mon, 29 May 2006 12:40:20 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F025D6591@esebe103.NOE.Nokia.com> In-Reply-To: <1148717295.447808ef3ad09@webmail.versatel.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Thread-Index: AcaBZLmmTPtO59EUQBmGW4sYPFJK0ABna0Uw From: To: , X-OriginalArrivalTime: 29 May 2006 09:40:21.0698 (UTC) FILETIME=[E765B220:01C68303] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >For example: section 3.4 in ountbound-03 on edge proxies, do=20 >we need to support such a deployment? I suppose so. >The current solution helps to locate the home registrar /=20 >proxy, but not edge proxies Why not ? I think it does. The starting point for the procedures described in sip-outbound-discovery is this: The procedures here are invoked when a UA needs to send a request via a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP) URI of the proxy without port, transport or maddr parameters as the next hop. Thus it only requires the UA to have a URI mapped to those edge proxies available. The UA may get this URI in several different ways (which are not in scope of this I-D but could be listed within the new requirements section to make this relation explicit): 1. The UA has been configured with the specific URI (the URI to be used to find the outbound proxy) that will be resolved into the=20 addresses of the edge proxies (either in the home or another=20 domain, depending on the network configuration). 2. The UA uses the AOR of the user to locate the edge proxies which=20 belong to the home domain. 3. The UA uses DHCP to locate edge proxies belonging to a visited domain. Regards, Erkki >-----Original Message----- >From: ext jbemmel@zonnet.nl [mailto:jbemmel@zonnet.nl]=20 >Sent: 27.May.2006 11:08 >To: Juha Heinanen >Cc: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sip@ietf.org; ft@it.su.se >Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to=20 >rely on NAPTR orTXT records ? > >Citeren Juha Heinanen : > >> jbemmel@zonnet.nl writes: >>=20 >> > Then how would they go about discovering a proxy that supports=20 >> > outbound + SIPSEC? >>=20 >> i cannot imagine a situation where my some of my domain's outbound >> proxies would support SIPSEC and some not. >>=20 > >Perhaps for the same reasons that some proxies would support=20 >outbound, and some not > >> > As for the next version of the discovery draft: I think a=20 >section on >> > the requirements that we're trying to meet (and=20 >> > also those that we're not) would be good.=20 >>=20 >> what outbound requirements we don't know about that would warrant >> delaying the document? > >For example: section 3.4 in ountbound-03 on edge proxies, do=20 >we need to support such a deployment? >The current solution helps to locate the home registrar /=20 >proxy, but not edge proxies > >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 May 29 09:23:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhfH-0002Vw-Dx; Mon, 29 May 2006 09:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhfF-0002Tb-JE for sip@ietf.org; Mon, 29 May 2006 09:20:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkhfD-00057i-3Z for sip@ietf.org; Mon, 29 May 2006 09:20:09 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 06:20:06 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="284638698:sNHT34203556" 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/8.12.11) with ESMTP id k4TDK65T007003; Mon, 29 May 2006 06:20:06 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4TDK6cL014940; Mon, 29 May 2006 06:20:06 -0700 (PDT) Received: from [192.168.1.2] ([10.21.113.88]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 06:20:05 -0700 In-Reply-To: References: <55B7DAD0-FE39-41F7-A068-B79CBC7A792E@softarmor.com> <6221A131-A715-42B3-BB91-2204D905AD8F@cisco.com> <446A2FF1.6020807@cisco.com> <28BAAAEB-D63A-498D-9EB1-2D1B6D58C082@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Mismatch in registry policy requirements of RFC 3969 Date: Mon, 29 May 2006 06:20:04 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 May 2006 13:20:05.0708 (UTC) FILETIME=[99ADF8C0:01C68322] DKIM-Signature: a=rsa-sha1; q=dns; l=4555; t=1148908806; x=1149772806; c=relaxed/simple; s=sjdkim8001; 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]=20Mismatch=20in=20registry=20policy=20requirements=20of=20 RFC=203969; X=v=3Dcisco.com=3B=20h=3DwUQdvhawa4bCU3L5RVZDcy/QkEc=3D; b=Qs3XUnwhXGjXJ5xMrG6kqkM8z3huf1Dg4kui+TuQ2nu9XCL25zvODkHC/55z8BsXK+mynRl+ oMI0MmIu7UrmEoNETrkAcinrGwuaIacO5xLhwipahu9By/Dt4JLjeP2n; 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: 67c1ea29f88502ef6a32ccec927970f0 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 Sorry, I did not mean to imply an I-D get created. I was just hoping that the chairs could figure out what the WG thinks about this. This could be based either on some new email or old email. It's not clear to me if the WG ever did decide this or not and if they did, I'm not trying to overturn some previous decision. I don't really see this as an IESG decision as much as something the WG should have rough consensus on and the IESG can check for sanity and approve. A single paragraph in email that said what the WG wanted supported why this was the decision would be great. I will pass that by the IESG and make sure no one objects and then get IANA to make the change. If someone wanted to bother to file an errata on the RFC that would be a bonus. Cullen On May 22, 2006, at 3:26 PM, Dean Willis wrote: > > Normally all it takes is a note from the AD saying "The IESG's > intent was as specified by the second paragraph, standards-track > RFC required". > > But we'll be happy to drive to WG Consensus if you want. Shall we > document this in the form of an internet-draft? > > -- > Dean > > > On May 22, 2006, at 2:17 PM, Cullen Jennings wrote: > >> >> This is clearly a bug in the spec. Would it be possible for the >> chairs to drive this to WG consensus before or during next >> meeting, get someone to file an errata, and then I will ask for >> IESG to review and get IANA updated to match the errata. Sounds >> like a reasonable plan? >> >> Cullen >> >> >> On May 16, 2006, at 1:02 PM, Jonathan Rosenberg wrote: >> >>> I'd suggest that it probably should be standards track. URI >>> parameters are a bigger deal than headers, I think, since they >>> are really making changes to the fundamental SIP addressing >>> architecture. I don't think that is something we want everyone >>> doing. >>> >>> -Jonathan R. >>> >>> Cullen Jennings wrote: >>> >>>> On May 9, 2006, at 8:54 PM, Dean Willis wrote: >>>>> >>>>> RFC 3969 defines the registry for SIP/SIPS URI parameters. >>>>> >>>>> It currently says: >>>>> >>>>> 4.2. Registration Policy for SIP and SIPS URI Parameters >>>>> >>>>> As per the terminology in RFC 2434 [4], the registration >>>>> policy for >>>>> SIP and SIPS URI parameters shall be "Specification Required". >>>>> >>>>> For the purposes of this registry, the parameter for which IANA >>>>> registration is requested MUST be defined by a standards- >>>>> track RFC. >>>>> >>>>> >>>>> Note that the above two paragraphs seem to be self >>>>> contradictory. "Specification Required" means 3GPP and >>>>> recognized bodies can define parameters by publishing >>>>> specifications. But"Standards Track RFC" means only IETF can >>>>> do so, and it has to be done with an IETF- consensus standards- >>>>> track document. >>>>> >>>>> Note that the IANA registry currently says: >>>>> >>>>> >>>>> SIP/SIPS URI Parameters RFC3969 Specification Required >>>>> >>>>> SIP/SIPS URI Parameters - per [RFC3969] >>>>> (New registrations are via Specification Required) >>>>> >>>>> This means that the current IANA policy for this registry is >>>>> "Specification Required". >>>>> >>>>> >>>>> Which did we mean? >>>> We might want to check with Allison on history of this but my >>>> vague recollection was last time we discussed this, we decided >>>> we meant "Standards Track". I forget the details and may be >>>> totally wrong. >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Cisco Fellow Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 29 14:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkme9-00059y-FP; Mon, 29 May 2006 14:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkme8-00059t-SQ for sip@ietf.org; Mon, 29 May 2006 14:39:20 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkme7-0003Zv-FJ for sip@ietf.org; Mon, 29 May 2006 14:39:20 -0400 Received: (qmail 27143 invoked by uid 0); 29 May 2006 18:39:03 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 May 2006 18:39:03 -0000 Message-ID: <005501c6834f$258dc1a0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F025D6591@esebe103.NOE.Nokia.com> Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Mon, 29 May 2006 20:38:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki, see inline Regards, Jeroen >The current solution helps to locate the home registrar / >proxy, but not edge proxies Why not ? I think it does. The starting point for the procedures described in sip-outbound-discovery is this: The procedures here are invoked when a UA needs to send a request via a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP) URI of the proxy without port, transport or maddr parameters as the next hop. Thus it only requires the UA to have a URI mapped to those edge proxies available. The UA may get this URI in several different ways (which are not in scope of this I-D but could be listed within the new requirements section to make this relation explicit): 1. The UA has been configured with the specific URI (the URI to be used to find the outbound proxy) that will be resolved into the addresses of the edge proxies (either in the home or another domain, depending on the network configuration). 2. The UA uses the AOR of the user to locate the edge proxies which belong to the home domain. 3. The UA uses DHCP to locate edge proxies belonging to a visited domain. [JvB] OK, so then you have found an edge proxy that supports outbound. How do you then ensure that this edge proxy forwards the REGISTER to a registrar that also supports 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 May 29 14:54:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkmqz-0001Y4-SF; Mon, 29 May 2006 14:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkmqy-0001Xz-LT for sip@ietf.org; Mon, 29 May 2006 14:52:36 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkmqx-00055l-Fe for sip@ietf.org; Mon, 29 May 2006 14:52:36 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 220C36C017 for ; Mon, 29 May 2006 14:52:31 -0400 (EDT) Subject: Re: [Sip] draft-ietf-sip-fork-loop-fix-01 : deprecate spirallingfor forking proxies From: "Dale R. Worley" To: Sip In-Reply-To: <004601c682ea$b9390dc0$31713b51@BEMBUSTER> References: <001201c6790e$f7547c10$31713b51@BEMBUSTER> <1148867141.28687.65.camel@niagra.pingtel.com> <004601c682ea$b9390dc0$31713b51@BEMBUSTER> Content-Type: text/plain Date: Mon, 29 May 2006 14:52:30 -0400 Message-Id: <1148928750.17999.1.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: sip@ietf.org X-Mailman-Version: 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-05-29 at 08:40 +0200, Jeroen van Bemmel wrote: > But since you're pointing it out: for a forking proxy, which by definition > must be stateful, I think you can make a forking proxy that is not stateful, by burying the needed information in the Vias that the proxy constructs. Not that that would be a very useful thing. 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 May 29 15:09:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkn5u-0006QL-Ey; Mon, 29 May 2006 15:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkn5t-0006QG-7g for sip@ietf.org; Mon, 29 May 2006 15:08:01 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkn5s-0006Y5-1Z for sip@ietf.org; Mon, 29 May 2006 15:08:01 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 907FF6C017 for ; Mon, 29 May 2006 15:07:52 -0400 (EDT) Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips From: "Dale R. Worley" To: Sip In-Reply-To: <200605290322.40468.dean.willis@softarmor.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> Content-Type: text/plain Date: Mon, 29 May 2006 15:07:52 -0400 Message-Id: <1148929672.17999.5.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 > > i don't disagree with you that end-to-end TLS would be a good thing. > > but it does make a difference if NSA needs to get to operators computer, > > because then they need physical access to operators computer room, which > > is difficult to do unnoticed. If the NSA needs to be *let into* the computer rooms of network operators, it's not doing its job. They've got submarines for tapping trans-oceanic fiber cables... But I'm hoping we can make the job hard enough that not every private investigator with $1,000 can get anything he wants. 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 May 29 21:10:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksiC-00054w-FS; Mon, 29 May 2006 21:07:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FksiB-00051o-00 for sip@ietf.org; Mon, 29 May 2006 21:07:55 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fksi9-0000pM-O4 for sip@ietf.org; Mon, 29 May 2006 21:07:54 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2A1A86C017 for ; Mon, 29 May 2006 21:07:49 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CF4@not01-mxc01.citel.com> References: <592CA2F7E2BFBD4088AC87ECFF34BECE2D6CF4@not01-mxc01.citel.com> Content-Type: text/plain Date: Mon, 29 May 2006 21:07:48 -0400 Message-Id: <1148951268.17999.24.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] Re: RFC4235 Dialog Event package 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 On Fri, 2006-03-03 at 14:44 +0000, Michael Procter wrote: > [...] the question of > what is meant by the mandatory "entity" attribute in the dialog-info > element. > > >From RFC4235 Section 4.1: > o entity: This attribute contains a URI that identifies the user > whose dialog information is reported in the remainder of the > document. This user is referred to as the "observed user". > > There doesn't appear to be any further discussion of what the entity > value should be, but all the examples in the RFC are apparently AORs. > (Except for the example in 4.2, which is missing the element altogether!) I was hoping that there would be more discussion of this question. > So, it seems likely that the intention was that an AOR be used, but > there appear to be good and not-so-good reasons to use a contact > URI/GRUU instead. I would like to understand what the entity > element is for (any use-cases?) and why it is mandatory. Any > clarifications to the usage could be added to Dale's draft. I've recently been working on the implementation of the dialog event package in our "parked call server", and what I am discovering is this: It's clear in practice how dialogs are grouped based on "what user they are destined for"; the conceptual design of a UA seems to always generate this grouping. Which makes it easy to determine, from the request-URI of the SUBSCRIBE, which group of dialogs to report in the dialog event package. What is *not* clear is what URI should be used to describe this group. It's possible for the group to "naturally" have an AOR, a GRUU, and more than one IP-based contact address (e.g., if the UA makes connections through a NAT as well as directly). (Well, presumably if it has a GRUU, it doesn't use IP contact addresses.) And of course, the request-URI for the SUBSCRIBE in question. Currently, our implementation uses the "local network" contact address, because that is always defined. There is also the messy case that in some situations, one has a multi- line phone instrument. Note that while each line of the instrument has one or more well-defined URIs, the instrument *as a whole* does not. And sometimes one wants information about all calls active on the instrument, not just on the line. (Consider "camp-on", when a held call is to ring the phone when it is no longer active.) 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 May 30 00:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkvO5-0007rd-J0; Mon, 29 May 2006 23:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkvO4-0007rY-L8 for sip@ietf.org; Mon, 29 May 2006 23:59:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkvO3-0000TV-CH for sip@ietf.org; Mon, 29 May 2006 23:59:20 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 20:59:19 -0700 X-IronPort-AV: i="4.05,186,1146466800"; d="scan'208"; a="284842188:sNHT32450908" 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/8.12.11) with ESMTP id k4U3xI7M031780; Mon, 29 May 2006 20:59:18 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4U3xHcL029230; Mon, 29 May 2006 20:59:17 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 20:59:17 -0700 In-Reply-To: <17530.33607.493642.294594@rautu.tutpro.com> References: <00a801c66ae6$ecc7d7a0$91c8000a@acmepacket.com> <8B1D53AEF7B03449A6D3771B3B7F850F0243FC0C@esebe103.NOE.Nokia.com> <17500.61784.185527.783328@rautu.tutpro.com> <1148855075.28687.39.camel@niagra.pingtel.com> <17530.33607.493642.294594@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Primary vs. backup Date: Mon, 29 May 2006 20:59:16 -0700 To: Juha Heinanen , Rohan Mahy X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 03:59:17.0766 (UTC) FILETIME=[6C5B3A60:01C6839D] DKIM-Signature: a=rsa-sha1; q=dns; l=971; t=1148961558; x=1149825558; c=relaxed/simple; s=sjdkim5001; 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]=20Primary=20vs.=20backup; X=v=3Dcisco.com=3B=20h=3DlDQC2X+Le6HVsfDgn4TdHDaNPiE=3D; b=T/BgyN0gmt+DG4QSU3rqrVz+PNkjl6G1eMr6qciVCj+ZvVwFtdeD1EB+o5gaXkDlXT0pUndG W011Gt9DDrarzEHeFmvzY75wGUgp+cSLjSuOZmqDmwK1S0WOwPyQY5dX; 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: 7655788c23eb79e336f5f8ba8bce7906 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 agree with Juha that this primary/backup terminology is bogus. The problem is coming up with better terminology. On earlier version, I had tried to just refer to is as a set and picking one from the set. If someone has good suggestions on better terminology (or even better, a patch we can apply to the XML) it would be nice. On May 28, 2006, at 10:14 PM, Juha Heinanen wrote: > Dale R. Worley writes: > >> Unfortunately, we really do need to solve the problem of locating >> Outbound-capable servers using DNS records. But do we need to >> specify >> exactly which servers a UA must use, beyond the rather general >> preference and balancing rules of RFC 3263? > > dale, this is exactly what i have proposed in two or three emails to > this list already. since i don't remember anyone opposing, it > would be > nice if the authors outbound would issue a new version where the > primary/backup distinction has been eliminated. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 00:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkvhy-0007Y6-K6; Tue, 30 May 2006 00:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkvhx-0007Y1-5X for sip@ietf.org; Tue, 30 May 2006 00:19:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkvhv-00024t-TI for sip@ietf.org; Tue, 30 May 2006 00:19:53 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 21:19:51 -0700 X-IronPort-AV: i="4.05,186,1146466800"; d="scan'208"; a="284848845:sNHT68319538" 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/8.12.11) with ESMTP id k4U4JpCZ023245; Mon, 29 May 2006 21:19:51 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4U4JocL004910; Mon, 29 May 2006 21:19:50 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 21:19:50 -0700 In-Reply-To: <17527.61047.777277.88525@rautu.tutpro.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F02598383@esebe103.NOE.Nokia.com> <1148674903.44776357ecd0e@webmail.versatel.nl> <17527.61047.777277.88525@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76F80DA4-26C7-49B2-98D7-C71AF8425911@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Mon, 29 May 2006 21:19:48 -0700 To: Juha Heinanen X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 04:19:50.0338 (UTC) FILETIME=[4B06CA20:01C683A0] DKIM-Signature: a=rsa-sha1; q=dns; l=517; t=1148962791; x=1149826791; c=relaxed/simple; s=sjdkim7001; 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-koivusalo-sip-outbound-discovery=20to=20rely=20on= 20NAPTR=20orTXT=20records=20?; X=v=3Dcisco.com=3B=20h=3Dq+cxVARDlx9HZTpbkG3gyl1cGoM=3D; b=kp5lSQ8GYf/ItnrNpN7dO1LuqU1NHNjc+LyjWltGDrin7d8s2jOzEOqWRWtO3wyUO380avUt RI3dtOnGJQO8g2dpE6usvZpsAY6vi1LbDLWFI8jyd/QwLk1XD85mJGW9; 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "sip@ietf.org" , "ft@it.su.se" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 26, 2006, at 11:15 PM, Juha Heinanen wrote: > >> Then how would they go about discovering a proxy that supports >> outbound + SIPSEC? > > i cannot imagine a situation where my some of my domain's outbound > proxies would support SIPSEC and some not. Again agreeing with Juha and generalizing somewhat to ... I can't imagine a situation where the set of proxies a UA would directly connect for registration of a single AOR would have significantly different properties or capabilities. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 00:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkvpl-0002DM-77; Tue, 30 May 2006 00:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkvpj-0002DB-Hm for sip@ietf.org; Tue, 30 May 2006 00:27:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkvph-0002Kl-8F for sip@ietf.org; Tue, 30 May 2006 00:27:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 21:27:53 -0700 X-IronPort-AV: i="4.05,186,1146466800"; d="scan'208"; a="284851867:sNHT33531636" 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/8.12.11) with ESMTP id k4U4Rq1g016351; Mon, 29 May 2006 21:27:52 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4U4RpIs004998; Mon, 29 May 2006 21:27:52 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 21:27:51 -0700 In-Reply-To: <44791444.1070109@softarmor.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <44771071.3020209@cisco.com> <17527.12693.959315.99788@rautu.tutpro.com> <44778963.9000102@cisco.com> <17527.61542.179767.847622@rautu.tutpro.com> <1148773008.2642.3.camel@dimension.cornfed.com> <44791444.1070109@softarmor.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49B7B49F-3CD8-43D2-B997-BB4F8005EAC7@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 29 May 2006 21:27:49 -0700 To: Dean Willis X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 04:27:51.0894 (UTC) FILETIME=[6A0E6760:01C683A1] DKIM-Signature: a=rsa-sha1; q=dns; l=1214; t=1148963272; x=1149827272; c=relaxed/simple; s=sjdkim6001; 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-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DE54Y2jKJfJW44o2SgsDknJKV26I=3D; b=b1nlWx7n0XTkpYmUGeTCFbnWEhV1RhdXV3WvPptZf5hBMBurU9W6bU5T3Z6YfMoNVwz6SyUN RvtVgsJKjmhDlCH2PEeEedrwteNDRu5A61dMoaElKx+AbUgC2pshuh2B; 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Sip' , "'Vijay K. Gurbani'" , Juha Heinanen , fwmiller@cornfed.com, 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 May 27, 2006, at 8:08 PM, Dean Willis wrote: > The session key is constructed based on an exchange of public-key > parts from each end. In that exchange, you get to see the > "fingerprint" of your partner's key. You can validate this against > a published fingerprint, if you have such available. > > If you don't, it works if you know the other party well enough to > verify to your satisfaction that you have reached the correct > party, and then go through the verbal fingerprint verification > process. > > If you connect to a party you don't know well enough to identify, > and you don't have a key for them, you can still do a verbal > verification of the fingerprint to at least know that there's not a > MITM. Of course, you still won't know who you're talking to. But at > least next time, you'll know your talking to them again. Unless or course the are using a different phone this time in which case you will come to the conclusion that this is not the same person. Of course no one has more than one phone. Of course there are solutions to this - I think ZRTP might want to include one of them as most people seem to have more than one phone. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 01:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkwNb-0007V5-Ip; Tue, 30 May 2006 01:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkwNa-0007Ur-P4 for sip@ietf.org; Tue, 30 May 2006 01:02:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkwNZ-00058d-Em for sip@ietf.org; Tue, 30 May 2006 01:02:54 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 22:02:53 -0700 X-IronPort-AV: i="4.05,186,1146466800"; d="scan'208"; a="284864467:sNHT33504168" 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/8.12.11) with ESMTP id k4U52qme025230 for ; Mon, 29 May 2006 22:02:52 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4U52qcL015589 for ; Mon, 29 May 2006 22:02:52 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 22:02:52 -0700 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <1148929672.17999.5.camel@niagra.pingtel.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Mon, 29 May 2006 22:02:51 -0700 To: Sip X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 05:02:52.0589 (UTC) FILETIME=[4E2B05D0:01C683A6] DKIM-Signature: a=rsa-sha1; q=dns; l=2873; t=1148965372; x=1149829372; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re=3A=20[Si p]=20draft-audet-sip-sips-guidelines=3A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DJzkV7efP/usg5Sk4HGg17j6fg/c=3D; b=LMJyzmReVa3oZrbV0G9AGqdnX/lBvxE8tSzyn+SHGrj026QQUG+bFN7uuZmUOtubmlwJ+ne/ hcoi0ic6+LIf4BX2QsYKBuNRS0GMrR8KQq8vdac8vLmNbVSrX4FnOHGg; 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: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 plan to very seldom sends emails with my AD hat on but I think I will make an exception for this one. This may be a learning experience for me in trying to provide some of that "Steering" part of the IESG role. sips is not analogous to https or the lock icon on a browser. When firefox puts up the lock icon, some of the things it tries to mean is that you are connected to the website you think you are connected and your data in encrypted. sips was never meant to imply that you were talking to the person in your To header field value or that your RTP is somehow encrypted. It does not solve either of those problems. We have several working groups in the RAI and Security area that are working to provide solutions to these two security issues and others. That sips does not provide these does not in any way mean that sips should be deprecated. In many situations, sips provides a very powerful security primitive that protects against several things. Many of these were brought up on this thread. I would like to point at one in particular. Imagine the hypothetical case where Brian has a phone at Neustar and trusts Neustar, and I have a phone at Cisco and trust Cisco. Using sips for a call that goes from Brains phone to the Neustar proxy to the Cisco proxy and to my phone provides a surprisingly strong system for many attacks. Note that Brian's proxy found no need to route the call through an AT&T proxy in the middle. Now Brian and I might not want to use this signaling channel for things that we did not want Cisco or Neustar to know about but this channel could help secure many things that were reasonable business items between Cisco and Neustar. In this case, sips can help be a tool that can be used to achieve the desired security. For communications where I would not trust Cisco or Nuestar, we will might use AOR at domains we trust for that purpose - like our own domains. I think that at the high level, the semantics of sips are simple. We want it to mean that every hop from the UAC to the UAS was integrity and confidentiality protected at a reasonable level assuming transitive trust. This can be very useful. At the more fine details level, we have some parts that are unclear in how to implement it, we probably have some bugs in the spec, and perhaps we even one place where we made a bad choice that we may correct. I'm very keen on this draft - I want it to try and sort out the details that are missing or wrong. sips is not the answer to every problem. Note even 3261 had S/MIME and we have done Identity, SRTP, and many more. However SIPS is a useful tool for creating security solutions and we should sort out any missing details. Cullen Now bring on the rotten vegetables. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 01:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkx1I-0005RR-25; Tue, 30 May 2006 01:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkx1G-0005RJ-7o for sip@ietf.org; Tue, 30 May 2006 01:43:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkx1E-0000nC-I9 for sip@ietf.org; Tue, 30 May 2006 01:43:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4U5hnx8009203; Tue, 30 May 2006 08:43:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 08:43:49 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 08:43:47 +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] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Tue, 30 May 2006 08:43:45 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F025D6A58@esebe103.NOE.Nokia.com> In-Reply-To: <005501c6834f$258dc1a0$31713b51@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Thread-Index: AcaDWgDVlFUoVhwZSFi5kuSot+N+vQAT9j+Q From: To: , X-OriginalArrivalTime: 30 May 2006 05:43:47.0936 (UTC) FILETIME=[05AB3E00:01C683AC] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >[JvB] OK, so then you have found an edge proxy that supports=20 >outbound. How=20 >do you then ensure that this edge proxy forwards the REGISTER=20 >to a registrar that also supports outbound? The registrar is the one in the home domain of the user. If I understand your question correctly the issue is that if the UA is able to automatically discover (in a visited network) that local proxies support SIP Outbound and consequently start using those extensions even if neither registrar or proxies in the home domain would not support SIP Outbound ? Yes, this could cause a kind of problem so that in the registrar the backup registration would override the primary registration. However if it causes the network to route all incoming requests via the backup flow, I do not still think it would make the communication from/to the UA to fail. But if this is something to be prevented, then I assume the solution would be to define a flag to the UA which indicates whether the registrar supports outbound or not. I did not have any plans to make automatic discovery for that, but WG members can tell their opinion on this. Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 >Sent: 29.May.2006 21:39 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); jh@tutpro.com >Cc: sip@ietf.org; ft@it.su.se >Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to=20 >rely on NAPTR orTXT records ? > >Erkki, > >see inline > >Regards, >Jeroen > >>The current solution helps to locate the home registrar / >>proxy, but not edge proxies > >Why not ? I think it does. The starting point for the procedures >described in sip-outbound-discovery is this: > > The procedures here are invoked when a UA needs to send a=20 >request via > a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP) > URI of the proxy without port, transport or maddr parameters as the > next hop. > >Thus it only requires the UA to have a URI mapped to those edge proxies >available. The UA may get this URI in several different ways (which are >not in scope of this I-D but could be listed within the new=20 >requirements >section to make this relation explicit): > >1. The UA has been configured with the specific URI (the URI to be > used to find the outbound proxy) that will be resolved into the > addresses of the edge proxies (either in the home or another > domain, depending on the network configuration). > >2. The UA uses the AOR of the user to locate the edge proxies which > belong to the home domain. > >3. The UA uses DHCP to locate edge proxies belonging to a visited > domain. > >[JvB] OK, so then you have found an edge proxy that supports=20 >outbound. How=20 >do you then ensure that this edge proxy forwards the REGISTER=20 >to a registrar=20 >that also supports 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 Tue May 30 02:00:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxFH-0001Mp-Hs; Tue, 30 May 2006 01:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxFG-0001Mk-Fo for sip@ietf.org; Tue, 30 May 2006 01:58:22 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxFD-00033v-2b for sip@ietf.org; Tue, 30 May 2006 01:58:22 -0400 Received: (qmail 3502 invoked by uid 0); 30 May 2006 05:58:14 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 May 2006 05:58:14 -0000 Message-ID: <004001c683ae$082db840$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Cullen Jennings" Date: Tue, 30 May 2006 07:58:10 +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.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org Subject: [Sip] more outbound-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: , Content-Type: multipart/mixed; boundary="===============1486119729==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1486119729== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C683BE.CB7894E0" This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C683BE.CB7894E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen, For deployments with edge proxies (3.4), do we need some way to ensure = that "primary" and "backup" flows don't end up at the same registrar = host?=20 Regards, Jeroen ------=_NextPart_000_003D_01C683BE.CB7894E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen,
 
For deployments with edge proxies = (3.4), do we need=20 some way to ensure that "primary" and "backup" flows don't end up at the = same=20 registrar host?
 
Regards,
 
Jeroen
------=_NextPart_000_003D_01C683BE.CB7894E0-- --===============1486119729== 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 --===============1486119729==-- From sip-bounces@ietf.org Tue May 30 02:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxMH-0004kM-DK; Tue, 30 May 2006 02:05:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxMG-0004jZ-Lm for sip@ietf.org; Tue, 30 May 2006 02:05:36 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxMF-0004Q0-6x for sip@ietf.org; Tue, 30 May 2006 02:05:36 -0400 Received: (qmail 8891 invoked by uid 0); 30 May 2006 06:05:31 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 30 May 2006 06:05:31 -0000 Message-ID: <005101c683af$0c4e6ea0$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <8B1D53AEF7B03449A6D3771B3B7F850F025D6A58@esebe103.NOE.Nokia.com> Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Tue, 30 May 2006 08:05:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki, I am not sure if this is something your draft should address; my point was that we don't have all the requirements clear and explicit yet. It is fine with me if you state "I did not have any plans to make automatic discovery for that", it's just that it would be good to make that explicit in the draft Regards, Jeroen ----- Original Message ----- From: To: ; Cc: ; Sent: Tuesday, May 30, 2006 7:43 AM Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Hi, >[JvB] OK, so then you have found an edge proxy that supports >outbound. How >do you then ensure that this edge proxy forwards the REGISTER >to a registrar that also supports outbound? The registrar is the one in the home domain of the user. If I understand your question correctly the issue is that if the UA is able to automatically discover (in a visited network) that local proxies support SIP Outbound and consequently start using those extensions even if neither registrar or proxies in the home domain would not support SIP Outbound ? Yes, this could cause a kind of problem so that in the registrar the backup registration would override the primary registration. However if it causes the network to route all incoming requests via the backup flow, I do not still think it would make the communication from/to the UA to fail. But if this is something to be prevented, then I assume the solution would be to define a flag to the UA which indicates whether the registrar supports outbound or not. I did not have any plans to make automatic discovery for that, but WG members can tell their opinion on this. Regards, Erkki >-----Original Message----- >From: ext Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >Sent: 29.May.2006 21:39 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); jh@tutpro.com >Cc: sip@ietf.org; ft@it.su.se >Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to >rely on NAPTR orTXT records ? > >Erkki, > >see inline > >Regards, >Jeroen > >>The current solution helps to locate the home registrar / >>proxy, but not edge proxies > >Why not ? I think it does. The starting point for the procedures >described in sip-outbound-discovery is this: > > The procedures here are invoked when a UA needs to send a >request via > a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP) > URI of the proxy without port, transport or maddr parameters as the > next hop. > >Thus it only requires the UA to have a URI mapped to those edge proxies >available. The UA may get this URI in several different ways (which are >not in scope of this I-D but could be listed within the new >requirements >section to make this relation explicit): > >1. The UA has been configured with the specific URI (the URI to be > used to find the outbound proxy) that will be resolved into the > addresses of the edge proxies (either in the home or another > domain, depending on the network configuration). > >2. The UA uses the AOR of the user to locate the edge proxies which > belong to the home domain. > >3. The UA uses DHCP to locate edge proxies belonging to a visited > domain. > >[JvB] OK, so then you have found an edge proxy that supports >outbound. How >do you then ensure that this edge proxy forwards the REGISTER >to a registrar >that also supports 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 Tue May 30 02:38:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxqK-0007gp-Um; Tue, 30 May 2006 02:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkxqJ-0007gh-4s for sip@ietf.org; Tue, 30 May 2006 02:36:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkxqH-0006sU-SU for sip@ietf.org; Tue, 30 May 2006 02:36:39 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 23:36:37 -0700 X-IronPort-AV: i="4.05,187,1146466800"; d="scan'208"; a="284900717:sNHT33255254" 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/8.12.11) with ESMTP id k4U6abAm005255; Mon, 29 May 2006 23:36:37 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4U6aaIs020442; Mon, 29 May 2006 23:36:36 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 23:36:36 -0700 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F025D6A58@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F025D6A58@esebe103.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44EF77BE-8E49-40A7-9C7E-E6E2D0CCD678@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ? Date: Mon, 29 May 2006 23:36:35 -0700 To: "" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 06:36:36.0818 (UTC) FILETIME=[66784320:01C683B3] DKIM-Signature: a=rsa-sha1; q=dns; l=738; t=1148970997; x=1149834997; c=relaxed/simple; s=sjdkim5001; 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-koivusalo-sip-outbound-discovery=20to=20rely=20on= 20NAPTR=20orTXT=20records=20?; X=v=3Dcisco.com=3B=20h=3Dq+cxVARDlx9HZTpbkG3gyl1cGoM=3D; b=iYq7LdX/EEp7ttukRe3EDE8xWkspbwpVBh1F42BAMXNOklkdD8MjhrAPgrEofv/EwQqBURdl U+P9jdwad6S1JFR4m4ABNbPBAUEuGnBLTepf9tzJ33SrBLwMfTByNoTP; 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: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, jh@tutpro.com, ft@it.su.se X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 29, 2006, at 10:43 PM, wrote: >> [JvB] OK, so then you have found an edge proxy that supports >> outbound. How >> do you then ensure that this edge proxy forwards the REGISTER >> to a registrar that also supports outbound? > I view it as there are two likely case at this point case 1) the "home" proxies/registrar support outbound case 2) the "home" proxies/registrar don't support outbound In case 1 - you sent it to them and things work In case 2 - you send it to them and they ignore the reg-id and things work as well as they do today which is less than optimal but the best we can do when the domain of your AOR does not support 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 Tue May 30 03:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkyaY-0000zG-Bl; Tue, 30 May 2006 03:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkyaX-0000zB-0z for sip@ietf.org; Tue, 30 May 2006 03:24:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkyaV-0002Dl-Nh for sip@ietf.org; Tue, 30 May 2006 03:24:25 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 30 May 2006 00:24:23 -0700 X-IronPort-AV: i="4.05,187,1146466800"; d="scan'208,217"; a="284923200:sNHT51948156" 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/8.12.11) with ESMTP id k4U7ONQ2017686; Tue, 30 May 2006 00:24:23 -0700 Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4U7ONcL005767; Tue, 30 May 2006 00:24:23 -0700 (PDT) Received: from [192.168.1.2] ([10.21.91.119]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 00:24:22 -0700 In-Reply-To: <004001c683ae$082db840$31713b51@BEMBUSTER> References: <004001c683ae$082db840$31713b51@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Message-Id: <0408E4D5-14B0-47F3-B663-561F0D53F4D0@cisco.com> From: Cullen Jennings Date: Tue, 30 May 2006 00:24:21 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 30 May 2006 07:24:23.0026 (UTC) FILETIME=[12DCE520:01C683BA] DKIM-Signature: a=rsa-sha1; q=dns; l=2819; t=1148973863; x=1149837863; c=relaxed/simple; s=sjdkim5001; 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=20more=20outbound-03; X=v=3Dcisco.com=3B=20h=3DRRbzf7qZLNcXzWCRRL+uI8fMxEQ=3D; b=NKIgZ4dkvLb2oPdDEPmFSNrZvnYhrHf62HdTnFUzWQYfuKauuWGGVT14muyKLB/gW+kwH+Ex XjV0QhBgyNd2PzHo/5rSSZQhwlDDpITTubcffeycMGLHIl0DOmbol9FW; Authentication-Results: sj-dkim-5.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org Subject: [Sip] Re: more outbound-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: , Content-Type: multipart/mixed; boundary="===============2123925831==" Errors-To: sip-bounces@ietf.org --===============2123925831== Content-Type: multipart/alternative; boundary=Apple-Mail-1-1015453736 --Apple-Mail-1-1015453736 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed For solving the high reliability problem - yes. Note that there have been a few proposed solutions to this and outbound as it is currently defined works with any of them On May 29, 2006, at 10:58 PM, Jeroen van Bemmel wrote: > Cullen, > > For deployments with edge proxies (3.4), do we need some way to > ensure that "primary" and "backup" flows don't end up at the same > registrar host? > > Regards, > > Jeroen > --Apple-Mail-1-1015453736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

For solving the high=A0reliability= =A0problem - yes.

Note that there have been a = few=A0proposed solutions to this and outbound as it is=A0currently = defined works with any of them

On May 29, 2006, = at 10:58 PM, Jeroen van Bemmel wrote:

=A0
=A0
=A0

= --Apple-Mail-1-1015453736-- --===============2123925831== 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 --===============2123925831==-- From sip-bounces@ietf.org Tue May 30 07:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl21W-0000LX-Io; Tue, 30 May 2006 07:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl21U-0000IE-81 for sip@ietf.org; Tue, 30 May 2006 07:04:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl21K-0006He-Ik for sip@ietf.org; Tue, 30 May 2006 07:04:28 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DAC8D761; Tue, 30 May 2006 13:04:13 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:04:13 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:04:13 +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: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Date: Tue, 30 May 2006 13:04:13 +0200 Message-ID: <5EB80D22825EEE42872083AD5BFFB594017F0FBD@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaDpxU5kqDMCUAARl607Inni2eOggAKGhZw From: "Christer Holmberg \(JO/LMF\)" To: "Cullen Jennings" , "Sip" X-OriginalArrivalTime: 30 May 2006 11:04:13.0329 (UTC) FILETIME=[C8E56810:01C683D8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 So, what you are saying: sips:brian@neustar.com =3D sip:brian@neustar.com Require: integrity-and-confidentiality-protection Proxy-Require: integrity-and-confidentiality-protection ? If so, and if people have problems with sips, and what it really means, why not then simply define an option tag to be used in a Require/Proxy-Require header? Regards, Christer =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 30. toukokuuta 2006 8:03 To: Sip Subject: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips I plan to very seldom sends emails with my AD hat on but I think I will make an exception for this one. This may be a learning experience for me in trying to provide some of that "Steering" part of the IESG role. sips is not analogous to https or the lock icon on a browser. When firefox puts up the lock icon, some of the things it tries to mean is that you are connected to the website you think you are connected and your data in encrypted. sips was never meant to imply that you were talking to the person in your To header field value or that your RTP is somehow encrypted. It does not solve either of those problems. We have several working groups in the RAI and Security area that are working to provide solutions to these two security issues and others. That sips does not provide these does not in any way mean that sips should be deprecated. In many situations, sips provides a very powerful security primitive that protects against several things. Many of these were brought up on this thread. I would like to point at one in particular. Imagine the hypothetical case where Brian has a phone at Neustar and trusts Neustar, and I have a phone at Cisco and trust Cisco. Using sips for a call that goes from Brains phone to the Neustar proxy to the Cisco proxy and to my phone provides a surprisingly strong system for many attacks. Note that Brian's proxy found no need to route the call through an AT&T proxy in the middle. Now Brian and I might not want to use this signaling channel for things that we did not want Cisco or Neustar to know about but this channel could help secure many things that were reasonable business items between Cisco and Neustar. In this case, sips can help be a tool that can be used to achieve the desired security. For communications where I would not trust Cisco or Nuestar, we will might use AOR at domains we trust for that purpose - like our own domains. I think that at the high level, the semantics of sips are simple. We want it to mean that every hop from the UAC to the UAS was integrity and confidentiality protected at a reasonable level assuming transitive trust. This can be very useful. At the more fine details level, we have some parts that are unclear in how to implement it, we probably have some bugs in the spec, and perhaps we even one place where we made a bad choice that we may correct. I'm very keen on this draft - I want it to try and sort out the details that are missing or wrong. sips is not the answer to every problem. Note even 3261 had S/MIME and we have done Identity, SRTP, and many more. However SIPS is a useful tool for creating security solutions and we should sort out any missing details. Cullen Now bring on the rotten vegetables. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 09:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl46K-0003va-Mm; Tue, 30 May 2006 09:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl46J-0003vV-3k for sip@ietf.org; Tue, 30 May 2006 09:17:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl46H-0002eX-SA for sip@ietf.org; Tue, 30 May 2006 09:17:35 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 May 2006 06:17:33 -0700 X-IronPort-AV: i="4.05,189,1146466800"; d="scan'208"; a="285132402:sNHT57399764" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4UDHX6v029833; Tue, 30 May 2006 06:17: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 k4UDHXCU013692; Tue, 30 May 2006 06:17:33 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn5-524.cisco.com [10.21.90.12]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4UDEDF1013339; Tue, 30 May 2006 06:14:15 -0700 Message-ID: <447C45F6.60907@cisco.com> Date: Tue, 30 May 2006 06:17:42 -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: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> In-Reply-To: <758F0645-1076-44CB-8121-05C921B9B335@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=345; t=1148995053; x=1149859053; c=relaxed/simple; s=sjdkim2001; 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=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=09draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5Z3eXCg7lQqehgEB9HfS2i5thd0=3D; b=cdh45M/RnNKHUHE/haCtTWd+wTYXkz4FffYlT6LRr2pVhz3o0bGcv37yF6RqjqXQehuzx3+Q gy9ny3JK0EobHDEqEo6vtYrWhntA6DyA0RovIBkrKqO2TXJEFQYx7Dub; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Cullen Jennings wrote: > sips is not the answer to every problem. My question is whether it's answer to _any_ problem. My last attempt at getting and answer was fruitless. What attacks do SIPS thwart in real life that honest operators and transport=tls doesn't? Real life good guy, bad guy situations would be helpful. 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 May 30 10:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4wh-0005TY-Kk; Tue, 30 May 2006 10:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4wb-0005TL-Fr for sip@ietf.org; Tue, 30 May 2006 10:11:37 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4wa-0005Xg-6m for sip@ietf.org; Tue, 30 May 2006 10:11:37 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4UEBWjV002332; Tue, 30 May 2006 09:11:32 -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 k4UEBWR24400; Tue, 30 May 2006 09:11:32 -0500 (CDT) Message-ID: <447C5294.9010107@lucent.com> Date: Tue, 30 May 2006 09:11:32 -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: Michael Thomas Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> In-Reply-To: <447C45F6.60907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Michael Thomas wrote: > My question is whether it's answer to _any_ problem. My last attempt at > getting and answer was fruitless. What attacks do SIPS thwart in real life > that honest operators and transport=tls doesn't? Real life good guy, bad > guy situations would be helpful. Sorry -- catching up after a forced, and not entirely un-welcome, lull introduced by the weekend. Dean has pointed out one answer to this; namely, "reduces the probability of an accidental downgrade by intermediate proxies between the UAC and the proxy responsible for the AOR, if those proxies bother to honor it." A couple more: sips provides confidentiality of traffic and authentication of a proxy and registrar to a UAC. Admittedly, one could do this with transport=tls, but this particular construct is deprecated in rfc3261. Currently, there is no means for a UAC to authenticate a registrar or a proxy; sips at the very least, allows for the signaling between the UAC and a registrar to be on an confidential and authenticated channel. To other services such as transporting presence, sips provides confidentiality. The semantics of transport=tls, if un-deprecated would be limited to next hop only; the semantics of sips -- if we tighten the spec up appropriately -- are confidentiality across all participating hops. To me, this sort of a construct is well worth it if it provides confidentiality for my presence information. 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 May 30 10:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl5NA-00063v-Rj; Tue, 30 May 2006 10:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl5N9-000615-OZ for sip@ietf.org; Tue, 30 May 2006 10:39:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl5N9-0000f1-NA for sip@ietf.org; Tue, 30 May 2006 10:39:03 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fl59T-0006XS-TR for sip@ietf.org; Tue, 30 May 2006 10:24:58 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4UEOsx19165; Tue, 30 May 2006 09:24:54 -0500 Date: Tue, 30 May 2006 09:24:54 -0500 Message-Id: <200605301424.k4UEOsx19165@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Cullen Jennings" , "Sip" Subject: RE: Wacky thead of the month award goes to ... Re: [Sip] X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 a nice encapsulation of the capabilities that are there. While I agree that depracating sips is probably not useful, its also clear IMHO that something needs to be put in place to allow for end-to-end secure signaling. If sips can be morphed simply to do that then lets do it. If it can't, lets forget about sips and figure out a way to solve the end-to-end problem. The end-to-end problem is hard given the basic architecture of SIP but is also the problem that once solved will really boost the usefulness of SIP in general, again, IMHO. FM ------------------------------------------------ On Mon, 29 May 2006 22:02:51 -0700, Cullen Jennings wrote: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 30 12:10:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6lK-0007rw-PA; Tue, 30 May 2006 12:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6lI-0007rh-OR for sip@ietf.org; Tue, 30 May 2006 12:08:04 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl6lH-00015L-HZ for sip@ietf.org; Tue, 30 May 2006 12:08:04 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 158B36C01D for ; Tue, 30 May 2006 12:07:58 -0400 (EDT) From: "Dale R. Worley" To: Sip In-Reply-To: <0408E4D5-14B0-47F3-B663-561F0D53F4D0@cisco.com> References: <004001c683ae$082db840$31713b51@BEMBUSTER> <0408E4D5-14B0-47F3-B663-561F0D53F4D0@cisco.com> Content-Type: text/plain Date: Tue, 30 May 2006 12:07:58 -0400 Message-Id: <1149005278.5457.15.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] "backup" outbound flows X-BeenThere: sip@ietf.org X-Mailman-Version: 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 get my brain refreshed in regard to the "backup flow" issue. My belief is that keeping a backup flow is intended to increase reliability. This can be true in only one sense -- When the primary flow fails, the agent can start using the backup flow without having to wait the time that it would require to set up another primary flow. And that this time delay would be a significant impediment to the type of reliability that we are attempting to provide. Naively, this seems plausible to me, but I'd like some confirmation that people have examined this assumption and know that it is significant. The second problem is "How to choose the backup flow target from the set of potential targets?" This is not as simple as it seems. For picking the primary flow, we just go through the list of servers in some preference order. But picking the backup flow is based not on the desirability of the backup target itself, but on minimizing the probability that both the primary and backup will fail simultaneously. And the optimal choice may depend on what was chosen as the primary. For example, sitting in Boston, my UA may prefer to connect with one of my provider's New York proxies. But the most likely failure mode might be "all New York proxies become inaccessible due to transmission line failure", in which case the backup should be *constrained* to be a Los Angeles proxy. OTOH, the most likely failure mode might be one proxy failing independently of all others, in which case, the backup should be the same as the second-most-preferred primary proxy, another New York proxy. There are other, messier, possibilities, which might be very difficult to model in a general DNS mechanism. 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 May 30 17:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBs6-0007dC-Cv; Tue, 30 May 2006 17:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlBs5-0007d2-3L for sip@ietf.org; Tue, 30 May 2006 17:35:25 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlBs3-0006Gl-O7 for sip@ietf.org; Tue, 30 May 2006 17:35:25 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4ULadYg008612 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 May 2006 16:36:40 -0500 In-Reply-To: <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Tue, 30 May 2006 16:35:17 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 May 30, 2006, at 12:02 AM, Cullen Jennings wrote: > > I think that at the high level, the semantics of sips are simple. > We want it to mean that every hop from the UAC to the UAS was > integrity and confidentiality protected at a reasonable level > assuming transitive trust. This can be very useful. At the more > fine details level, we have some parts that are unclear in how to > implement it, we probably have some bugs in the spec, and perhaps > we even one place where we made a bad choice that we may correct. > I'm very keen on this draft - I want it to try and sort out the > details that are missing or wrong. > "Correcting" the "bad choice" in the proposed way would be counter to the semantics you give above. It's been proposed that we should change RFC 3261 to require that, if sips: is used, then TLS MUST be used on all hops. This runs afoul of architectures where some other mechanism, notably IPSEC, is used on some hops. If we make this proposal a requirement, we end up in in a situation where we frequently cannot use sips: on the UAC to serving-proxy hops because some other security mechanism is used on the back side of the serving proxy. And since sips: is the only "please secure me" indicator we have, this means that we have no way to request any security treatment at all in this situation -- in short, that we're requiring people to NOT secure some links. This doesn't sound particularly rational. Perhaps what you really want is a rule more like "Proxies MUST NOT forward requests with a sips: URI onto links lacking reasonable integrity or confidentiality mechanisms. An example of a reasonable mechanism would be TLSThis would be roughly equivalent to a "Proxy- Require: link-security" option mechanism that I recall someone else proposing. This would actually benefit deployability, since it would also allow using sips: on calls from UACs that are using non-TLS (but secure) links to their proxies, whereas RFC 3261 as-is allows it only in the other direction. Now, let's consider retargeting -- the thing that serving proxies do when they replace a request-URI with a URI that was registered as a contact. It has been proposed that we adopt the rule "Proxies that retarget (change the request-URI) MUST NOT retarget a request that was originally targeted to a sips: URI to any other URI type." Well, that sort of does in forwarding your calls to a tel: URI while still getting the exposed SIP links protected. We could perhaps live with that, but it does seem to be a waste. Here at least we could get more mileage out of a proxy-require option tag that requires the resulting tel: request to traverse only secure links. But in any case, sips: remains only a marginal indicator of security. It's kind of like a note by the door of the office that says "Last one out, please lock the door". If somebody forgets, or choses not to, the door isn't locked, and nobody else knows. It's not the lack of security that gets me -- it's the lack of KNOWING that there is no security. Our current usage of sips: is no more secure and generally applicable to the Internet than the trust-domain protections around the privacy of P-Asserted-Identity are, and we made that a P-header. -- 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 May 30 18:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlClf-0002uB-Su; Tue, 30 May 2006 18:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCle-0002sU-EN for sip@ietf.org; Tue, 30 May 2006 18:32:50 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCld-0004Mk-4O for sip@ietf.org; Tue, 30 May 2006 18:32:50 -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 k4UMWi009065; Tue, 30 May 2006 18:32:45 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Date: Tue, 30 May 2006 17:32:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A189EA9@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaEMXz9CKm3QwI4S1+Wsccmn6uHrQABOgiQ From: "Francois Audet" To: "Dean Willis" , "Cullen Jennings" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 OK guys, It's good that I actually enjoyed my long week-end instead of diving into this thread. What I plan to do is update the draft before Montreal with some of the "open issues" that were flagged on this list. Or maybe I'll just write a bunch of slides on them. I will request some time for the topic... To summarize where I think we are, without diving into=20 endless pointless circular arguments: - OPEN ISSUE: Should we mandate TLS for all the hops when SIPS is used? - We have people on both sides of the arguement. - Everybody seem to agree that sips is NOT an indicator that end-to-end security will be used (or has been used).=20 - OPEN ISSUE: Should we deprecate completely sips, or should we clarify=20 what it means? - While we have people on both sides, I personally think that=20 deprecating it not a good idea at all, and am strongly in the "explain what it means" camp. We could even restrict where it can be used (e.g., in a Request-URI). Furthermore, we have a clear statement of direction from our AD along those lines. - There seem to be some broad agreement from the list that = transport=3Dtls shouldn't really be deprecated (as it is today in RFC 3261), but rather be used=20 to describe explicitely tls usage on a specific hop. This is different from=20 my current draft where I use sips in contacts for example, for that purpose.=20 I'm OK with the idea, and I think we have somewhat of a consensus (I haven't=20 seen anybody liking my attempt to use sips for that purpose in the draft). I can work this change into a new version of the 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 May 30 18:46:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCwm-0007SN-FQ; Tue, 30 May 2006 18:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCwk-0007SI-QC for sip@ietf.org; Tue, 30 May 2006 18:44:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlCwj-0005fe-Gn for sip@ietf.org; Tue, 30 May 2006 18:44:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 30 May 2006 15:44:16 -0700 X-IronPort-AV: i="4.05,191,1146466800"; d="scan'208"; a="1815743412:sNHT1495828686" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4UMiFUL006093; Tue, 30 May 2006 15:44:15 -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 k4UMiEKP008225; Tue, 30 May 2006 15:44:14 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn4-55.cisco.com [10.21.80.55]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4UMesKS025983; Tue, 30 May 2006 15:40:55 -0700 Message-ID: <447CCACA.10501@cisco.com> Date: Tue, 30 May 2006 15:44: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: "Vijay K. Gurbani" Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> In-Reply-To: <447C5294.9010107@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1860; t=1149029055; x=1149893055; c=relaxed/simple; s=sjdkim4001; 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=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5Z3eXCg7lQqehgEB9HfS2i5thd0=3D; b=aVZ52Fc0FBaxXyrUKR3OuK0/t81Xs1/MraX37d/hym0qiDfFOsJ5keY4aV2DsYDhb4wKy2wZ y024m8JBJ5DLPlFmhRHFM7Y3/t83SvkL6oTT5MaQ5Na1U3ThGMwy5eeQ; X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Vijay K. Gurbani wrote: > Michael Thomas wrote: > >> My question is whether it's answer to _any_ problem. My last attempt at >> getting and answer was fruitless. What attacks do SIPS thwart in real >> life >> that honest operators and transport=tls doesn't? Real life good guy, >> bad guy situations would be helpful. > > > Sorry -- catching up after a forced, and not entirely un-welcome, > lull introduced by the weekend. > > Dean has pointed out one answer to this; namely, "reduces the > probability of an accidental downgrade by intermediate proxies > between the UAC and the proxy responsible for the AOR, if those > proxies bother to honor it." How does it do that? Why does this sort of behavior require an ill conceived protocol element when it is really a BCP in disguise? > > A couple more: sips provides confidentiality of traffic > and authentication of a proxy and registrar to a UAC. Admittedly, > one could do this with transport=tls, but this particular > construct is deprecated in rfc3261. Currently, there is no means > for a UAC to authenticate a registrar or a proxy; sips at the > very least, allows for the signaling between the UAC and a > registrar to be on an confidential and authenticated channel. So SIPS is overloaded with transport=tls; Bletch. > > To other services such as transporting presence, sips provides > confidentiality. The semantics of transport=tls, if un-deprecated > would be limited to next hop only; the semantics of sips -- if we > tighten the spec up appropriately -- are confidentiality across > all participating hops. No. That is simply incorrect, and why this is so deeply problematic. And it leaves people with the mistaken impression that there is https style security when there is absolutely no way to test or count on that. 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 May 30 18:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCyu-00087z-Kk; Tue, 30 May 2006 18:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlCyt-00085C-5U for sip@ietf.org; Tue, 30 May 2006 18:46:31 -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 1FlCyr-0005vk-R7 for sip@ietf.org; Tue, 30 May 2006 18:46:31 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 30 May 2006 15:46:30 -0700 X-IronPort-AV: i="4.05,191,1146466800"; d="scan'208"; a="429319495:sNHT32713304" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4UMkTO9017319; Tue, 30 May 2006 15:46:29 -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 k4UMkT9s029229; Tue, 30 May 2006 15:46:29 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn4-55.cisco.com [10.21.80.55]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4UMh7pw026029; Tue, 30 May 2006 15:43:09 -0700 Message-ID: <447CCB4F.6090207@cisco.com> Date: Tue, 30 May 2006 15:46:39 -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: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips References: <1ECE0EB50388174790F9694F77522CCF0A189EA9@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A189EA9@zrc2hxm0.corp.nortel.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=2285; t=1149029189; x=1149893189; c=relaxed/simple; s=sjdkim3001; 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=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=09[Sip]draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DljOUObxET3Tj3qFUDAYmGSukmcI=3D; b=mFGxASwqJuPIrUp03ZPOAhKA7i5+rOEdKlkZW8jhg0bWwZYz41Gbw48lu6kCRXf0uYxEHn71 5gHa/KYs5htBMeWFajZGxC5H6w0TFSo24WS0J86Kmi+gd6HiIKGy8BDL; X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Cullen Jennings , Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think that the first and foremost thing to do here is determine what threats you are actually trying to prevent. The reason we are where we are now is because we "solved" the problem without knowing what the problem was. Mike Francois Audet wrote: >OK guys, > >It's good that I actually enjoyed my long week-end instead of diving >into this thread. > >What I plan to do is update the draft before Montreal with some of the >"open issues" that were flagged on this list. Or maybe I'll just write a >bunch of slides on them. I will request some time for the topic... > >To summarize where I think we are, without diving into >endless pointless circular arguments: > >- OPEN ISSUE: Should we mandate TLS for all the hops when SIPS is used? > - We have people on both sides of the arguement. > >- Everybody seem to agree that sips is NOT an indicator that end-to-end > security will be used (or has been used). > >- OPEN ISSUE: Should we deprecate completely sips, or should we clarify > what it means? > - While we have people on both sides, I personally think that > deprecating it not a good idea at all, and am strongly in the > "explain what it means" camp. We could even restrict where it > can be used (e.g., in a Request-URI). Furthermore, we have > a clear statement of direction from our AD along those lines. > >- There seem to be some broad agreement from the list that transport=tls > shouldn't really be deprecated (as it is today in RFC 3261), but >rather be used > to describe explicitely tls usage on a specific hop. This is different >from > my current draft where I use sips in contacts for example, for that >purpose. > I'm OK with the idea, and I think we have somewhat of a consensus (I >haven't > seen anybody liking my attempt to use sips for that purpose in the >draft). > I can work this change into a new version of the 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 Tue May 30 19:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPz-00014s-2a; Tue, 30 May 2006 19:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPs-0000pt-QD; Tue, 30 May 2006 19:14:24 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDPr-0001N0-Ep; Tue, 30 May 2006 19:14:24 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4UNENp8018965; Tue, 30 May 2006 16:14:23 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4UNENq9018964; Tue, 30 May 2006 16:14:23 -0700 Date: Tue, 30 May 2006 16:14:23 -0700 Message-Id: <200605302314.k4UNENq9018964@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4485 on Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4485 Title: Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) Author: J. Rosenberg, H. Schulzrinne Status: Informational Date: May 2006 Mailbox: jdrosen@cisco.com, schulzrinne@cs.columbia.edu Pages: 23 Characters: 57278 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-guidelines-09.txt URL: http://www.rfc-editor.org/rfc/rfc4485.txt The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. This memo provides information for the Internet community. This document is a product of the Session Initiation Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 30 19:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPd-0000hU-FT; Tue, 30 May 2006 19:14:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlDPa-0000gc-3K; Tue, 30 May 2006 19:14:06 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlDPY-0001Lz-Nd; Tue, 30 May 2006 19:14:06 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k4UNE43N018950; Tue, 30 May 2006 16:14:04 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k4UNE4q6018949; Tue, 30 May 2006 16:14:04 -0700 Date: Tue, 30 May 2006 16:14:04 -0700 Message-Id: <200605302314.k4UNE4q6018949@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4483 on A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4483 Title: A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages Author: E. Burger, Ed. Status: Standards Track Date: May 2006 Mailbox: eburger@cantata.com Pages: 17 Characters: 36794 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-content-indirect-mech-05.txt URL: http://www.rfc-editor.org/rfc/rfc4483.txt This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 30 21:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFbA-0005Zm-Ov; Tue, 30 May 2006 21:34:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlFb9-0005Zh-H1 for sip@ietf.org; Tue, 30 May 2006 21:34:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlFb8-0006Mm-5c for sip@ietf.org; Tue, 30 May 2006 21:34:11 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4V1Z9AL009517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 30 May 2006 20:35:20 -0500 In-Reply-To: <447CCACA.10501@cisco.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <447CCACA.10501@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Tue, 30 May 2006 20:33:48 -0500 To: Michael Thomas X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Sip , "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 May 30, 2006, at 5:44 PM, Michael Thomas wrote: >> >> Dean has pointed out one answer to this; namely, "reduces the >> probability of an accidental downgrade by intermediate proxies >> between the UAC and the proxy responsible for the AOR, if those >> proxies bother to honor it." > > > How does it do that? Why does this sort of behavior require an ill > conceived protocol element when it is really a BCP in disguise? > Because we operate with the presumptions that 1 ) most people don't want security, and 2) proxies will be extremely careless with our data unless we politely ask them not to. Further, we want to tell the proxies that if they aren't willing to be careful with our data, we'd rather they tell us up front so we can take our data elsewhere. Therefore, we need a protocol element to be able to ask the proxy to do what was probably "the right thing" all along. >> To other services such as transporting presence, sips provides >> confidentiality. The semantics of transport=tls, if un-deprecated >> would be limited to next hop only; the semantics of sips -- if we >> tighten the spec up appropriately -- are confidentiality across >> all participating hops. > > > No. That is simply incorrect, and why this is so deeply problematic. > And it leaves people with the mistaken impression that there is > https style security when there is absolutely no way to test or > count on that. Well, it sort of provides confidentiality, except to the proxies, as long as the proxies really are as careful with our data as we asked them to be which they may or may not be and we have no way of verifying. Sometimes, as Cullen has pointed out, this is good enough, or at least enough better than nothing that it is worth having. Ok, I am failing to reassure myself here. I'm detecting five different use cases that people are asking for: 1) I don't care about security, just make it work. 2) Use as much security as you can, but I'm willing to accept downgrades without being informed if you must. 3) I want hop-by-hop security that provides protections roughly equivalent to TLS if it were used on a hop-by-hop basis, and I want my request aborted and to be informed on it if you can't make that happen. 4) I want hop-by-hop protection using TLS, and I want my request aborted and to be informed on it if you can't make that happen. 5) I want my signaling locked-down end-to-end, and insist on being able to verify that this is the case. And if we exchange media, I want that locked-down too, and I want to be able to verify that too. Right now, I think we're arguing about a) whether sips: means case 2, 3, or 4. b) If sips: doesn't include case 2, do we need another mechanism for that, and 3) whether any of case 2, 3, or 4 are really useful. Personally I see some value in cases 2 and 3, none in case 4 that isn't achieved by 3, and a whole lot more in the currently unobtainable case 5, for which Vijay has proposed the new URI class "sipsec:" 3261, oddly enough, doesn't address any of these use cases. Rather, it says "I want hop-by-hop protection using TLS as far as the proxy corresponding to the request-URI, and and I want my request aborted and to be informed on it if you can't make that happen. After the request has reached the node corresponding to the request-URI, I want as much security as possible, but leave the selection and application of that security in the hands of the callee and its supporting nodes. If the callee didn't register with a sips: contact or happens to be a PSTN gateway, I still want the call to go through, and I don't need to be notified about the change in the security envelope. -- 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 May 31 01:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJWJ-0004cc-0t; Wed, 31 May 2006 01:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJWH-0004cW-O1 for sip@ietf.org; Wed, 31 May 2006 01:45:25 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlJPc-0003Pc-Em for sip@ietf.org; Wed, 31 May 2006 01:38:33 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 31 May 2006 07:38:28 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 31 May 2006 07:38:28 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A50F@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: fluffy@cisco.com Subject: AW: [Sip] Connected-identity and changing the To header field ina response Date: Wed, 31 May 2006 07:38:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.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 These are the requirements we already expressed in our draft = draft-jesske-sipping-tispan-requirements-02: REQ-TIP-1: In addition to any network asserted identity, it must be possible for the callee to indicate in a SIP response an additional identity where the user is reachable for = future direct communications. Note that the requirement refers to the user, not to the same instance of the User Agent. REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be formatted as = a SIP URI [2] or TEL URL [3]. A translation between SIP = URI and TEL URL by the network is not requested. REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end user supplied information that is not asserted by the network. As you can see we do not need any authenticated identity in the = response. For the authenticated identity we are using the = P-Asserted-Identity. So we have two identities in a Response. For our purposes the user provided identity in a final 200 OK response = is sufficient. So that avoids confusion within forking cases. Roland > -----Urspr=FCngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Gesendet: Montag, 22. Mai 2006 17:32 > An: Jesske, Roland > Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer=20 > Holmberg (JO/LMF) > Betreff: Re: [Sip] Connected-identity and changing the To=20 > header field ina response >=20 >=20 >=20 > On May 16, 2006, at 7:07 AM, Jesske, R wrote: >=20 > > John, > > it is that we don't can get an connected identity within the final = > > response of the initial INVITE. > > Your draft proposes a mid dialog request for getting this=20 > information. > > That is not usable for the TIP service. >=20 > I think this is part of what I am not understanding. What is the =20 > requirement here? >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 31 02:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJtY-0005fe-Cg; Wed, 31 May 2006 02:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJt4-0005Zu-Gy for sip@ietf.org; Wed, 31 May 2006 02:08:58 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlJns-0006fT-6t for sip@ietf.org; Wed, 31 May 2006 02:03:37 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 31 May 2006 08:03:35 +0200 Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 31 May 2006 08:03:34 +0200 Message-Id: <85108216918A984C8C60172D7C84770A08A510@S4DE8PSAAGO.mitte.t-com.de> From: "Jesske, R" To: fluffy@cisco.com Subject: AW: [Sip] Issue 1 in draft-ietf-sip-connected-identity-00.txt Date: Wed, 31 May 2006 08:03:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sip@ietf.org, esasaki@NTT-AT.COM, chister.holmberg@ericsson.com, john.elwell@siemens.com, christer.holmberg@ericsson.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 The problem is that we try to solve two different approaches. 1. The identity approach to get back an authenticated identity of the = connected user 2. To get back an "additional connected identity" that is = unauthenticated and provided by the user.=20 Due to Jon's comments these are valid for the first case but does not = harm the 2nd case. So we need the "unanticipated respondent" problem does not exist, = because we need only the "additional connected identity" in a final = 200OK Response. Looking on the second concern from Jon. That does not exist for our = used cases, because we have also included a P-Asserted-Identity in our = responses that identifies the Callee with a public identity so that the = called user cannot cheat with the "additional connected identity". The last problem of appearing the "additional connected identity" in = Final responses like the 403 does not appear if we are using the = "additional connected identity" only in 200 OK. So at least we need only an "additional connected identity" when the = called UA sends back a 200OK. Perhaps that was misleading in the past = discussion that I didn't express this requirement well. But nevertheless question for me is now how to go forward. Could we use = the "dialogUriChange" for this narrowed scope or not. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Gesendet: Dienstag, 23. Mai 2006 04:22 > An: Jesske, Roland > Cc: chister.holmberg@ericsson.com; sip@ietf.org;=20 > christer.holmberg@ericsson.com; esasaki@NTT-AT.COM;=20 > john.elwell@siemens.com > Betreff: Re: [Sip] Issue 1 in = draft-ietf-sip-connected-identity-00.txt >=20 >=20 >=20 > On May 8, 2006, at 3:52 AM, Jesske, R wrote: >=20 > > The discussion showed it that there is no harm in changing the to =20 > > header field in a response. >=20 > I think there has been several emails that point out the=20 > implications =20 > of this do cause harm (check out pretty much any post on the subject = > from Jon Peterson). >=20 > This has been a very long running debate and was discussed for =20 > several years with agenda time at many meetings. The change the To =20 > and put Identity in response solution has been considered and=20 > I think =20 > people have tried to explain the issues with it - I'm glad to spend =20 > some more time explaining that. However, much more productive would =20 > be trying to move off of this solution a little and look at the =20 > requirements. What do we need to do - I think there are some straw-=20 > man proposal that meet many of the requirements and do work. =20 > Understanding what requirements they have issues would would be good = > and help make them so they could be used. >=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 May 31 03:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKry-0004lh-H1; Wed, 31 May 2006 03:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlKrw-0004lS-7l for sip@ietf.org; Wed, 31 May 2006 03:11:52 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlKrq-0002tm-QX for sip@ietf.org; Wed, 31 May 2006 03:11:52 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 611601400A6; Wed, 31 May 2006 10:11:40 +0300 (EEST) Received: from rautu (unknown [213.132.115.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id DF93E13F989; Wed, 31 May 2006 10:11:30 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 2E624F03DC; Tue, 30 May 2006 23:07:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17532.42511.131915.278909@rautu.tutpro.com> Date: Tue, 30 May 2006 23:07:43 +0300 From: Juha Heinanen To: "Vijay K. Gurbani" Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <447C5294.9010107@lucent.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Sip , Michael Thomas X-BeenThere: sip@ietf.org X-Mailman-Version: 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 writes: > A couple more: sips provides confidentiality of traffic > and authentication of a proxy and registrar to a UAC. Admittedly, > one could do this with transport=tls, but this particular > construct is deprecated in rfc3261. transport=tls is used in practise, because no other ways exist to tell that tls is to be used on the next hop. there is thus still need for it and sips is not a replacement due to its end-to-end nature. -- 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 Wed May 31 09:39:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQsg-000399-9w; Wed, 31 May 2006 09:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQse-000394-Ce for sip@ietf.org; Wed, 31 May 2006 09:37:00 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQsd-0004f2-Pc for sip@ietf.org; Wed, 31 May 2006 09:37:00 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VDavSx024111; Wed, 31 May 2006 16:36:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:36:53 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 16:36:53 +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] "backup" outbound flows Date: Wed, 31 May 2006 16:36:51 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> In-Reply-To: <1149005278.5457.15.camel@niagra.pingtel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] "backup" outbound flows Thread-Index: AcaEBDP7GI1jNbKoTYSGCLLdiG5LnwArdV7A From: To: , X-OriginalArrivalTime: 31 May 2006 13:36:53.0364 (UTC) FILETIME=[471D9340:01C684B7] X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dale, I think you have raised good questions, indeed:=20 >My belief is that keeping a backup flow is intended to increase >reliability. > >This can be true in only one sense -- When the primary flow fails, the >agent can start using the backup flow without having to wait the time >that it would require to set up another primary flow. And that this >time delay would be a significant impediment to the type of reliability >that we are attempting to provide. Naively, this seems=20 >plausible to me, >but I'd like some confirmation that people have examined this=20 >assumption and know that it is significant. After working some time with the I-D specifying how the UA might find target hosts for primary and backup flows I started to think about what the UA would do with those multiple flows. I was able to make the following conclusions: In the introduction section draft-ietf-sip-outbound-03 says: There are many environments for SIP [5] deployments in which the User Agent (UA) can form a connection to a Registrar or Proxy but in which the connections in the reverse direction to the UA are not possible. This can happen for several reasons. Connection to the UA can be blocked by a firewall device between the UA and the proxy or registrar, which will only allow new connections in the direction of the UA to the Proxy. Similarly there may be a NAT, which are only capable of allowing new connections from the private address side to the public side. This specification allows SIP registration when the UA is behind such a firewall or NAT. ... The key idea of this specification is that when a UA sends a REGISTER request, the proxy can later use this same network "flow"--whether this is a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept of another transport protocol--to forward any requests that need to go to this UA. For a UA to receive incoming requests, the UA has to connect to a server. Since the server can't connect to the UA, the UA has to make sure that a flow is always active. This requires the UA to detect when a flow fails. Since, such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to use multiple flows to the proxy or registrar. Having multiple flows only helps if those flows are not likely=20 to fail at the same time. In draft-ietf-sip-outbound-03 and my=20 I-D considerable amount of effort has been spent to ensure that=20 those multiple flows would be set up to different proxy servers,=20 thus providing protection against a failing proxy.=20 However as the introduction says, the key reason behind writing=20 the draft-ietf-sip-outbound-03 are the NAT and firewall boxes=20 between the UA and those proxies. Do the those middleboxes=20 typically introduce a single point of failure that would make=20 all flows to fail simultaneously ? In my understanding this=20 would be the typical case, as usually the UA has only a single=20 network interface towards a local network that interconnects to the external networks over a single NAT or firewall. Even if the network would have different NATs or firewalls towards=20 different external networks, it would require very detailed=20 knowledge of the network configuration to select the proxies=20 such a way that each flow would be routed via a different=20 middlebox. So putting the issue together: if the NAT / firewall traversal is the key issue for draft-ietf-sip-outbound-03, does introduction of multiple redundant flows actually increase the likelihood of having a flow alive so much that it is worth the effort and additional traffic for keepalives ? >The second problem is "How to choose the backup flow target=20 >from the set >of potential targets?" This is not as simple as it seems. For picking >the primary flow, we just go through the list of servers in some >preference order. But picking the backup flow is based not on the >desirability of the backup target itself, but on minimizing the >probability that both the primary and backup will fail simultaneously. >And the optimal choice may depend on what was chosen as the primary. > >For example, sitting in Boston, my UA may prefer to connect with one of >my provider's New York proxies. But the most likely failure mode might >be "all New York proxies become inaccessible due to transmission line >failure", in which case the backup should be *constrained* to be a Los >Angeles proxy. OTOH, the most likely failure mode might be one proxy >failing independently of all others, in which case, the backup=20 >should be >the same as the second-most-preferred primary proxy, another New York >proxy. There are other, messier, possibilities, which might be very >difficult to model in a general DNS mechanism. In the example you gave the optimal choice does not only depend on=20 which server was chosen as the primary but also whether you would=20 like to optimize towards "maximum likelihood that at least one flow=20 stays alive" or "minimum impact to the service quality of only one=20 proxy fails". With only two flows (one primary and one backup) it is impossible=20 to reach both those aims simultaneously, regardless of whether those two target hosts are determined by UA configuration or DNS queries. You can however achieve that, if the UA can be configured with e.g. three proxy URIs (two for New York and one for LA, the New York proxies having precedence over that in LA). The aim in the coming version of draft-koivusalo-sip-outbound-discovery is this: REQ-OUTB-DISC-04: The size of the outbound-proxy-set discovered automatically must reach at least the minimum size specified in draft-ietf-sip-outbound (i.e. 2) The solution outlined in the I-D targets to meet this minimum requirement so that the UA would set up (one or) two flows, unless explicit configuration=20 of multiple URIs are given. How the UA selects the target host for its second backup flow is based on algorithm, relying on the priority and weight values of SRV records. By configuring those SRV records in an appropriate way the service provider should be able to achieve different kind of redundancy schemes, also based on geographical location if needed. P.S. I try to send draft-koivusalo-sip-outbound-discovery-01 over today so that you would be able to have a look into its details. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 31 10:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRLm-0006ZE-Oj; Wed, 31 May 2006 10:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRLl-0006Z5-Qu for sip@ietf.org; Wed, 31 May 2006 10:07:05 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRLj-0007MV-FT for sip@ietf.org; Wed, 31 May 2006 10:07:05 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 2276213F920; Wed, 31 May 2006 17:07:00 +0300 (EEST) Received: from rautu (guanine60.gprs.dnafinland.fi [62.78.120.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id A069013F91F; Wed, 31 May 2006 17:06:53 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id 3679CF03C5; Wed, 31 May 2006 15:16:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.35080.160755.383524@rautu.tutpro.com> Date: Wed, 31 May 2006 15:16:08 +0300 From: Juha Heinanen To: "Francois Audet" Subject: RE: Wacky thead of the month award goes to ... Re: [Sip]draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <1ECE0EB50388174790F9694F77522CCF0A189EA9@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF0A189EA9@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Cullen Jennings , Sip , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > - OPEN ISSUE: Should we deprecate completely sips, or should we clarify > what it means? > - While we have people on both sides, I personally think that > deprecating it not a good idea at all, and am strongly in the > "explain what it means" camp. i proposed that we deprecate SIPS UNTIL it's meaning is well defined (which according to SIP WG current practise may take MANY years). it -- 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 Wed May 31 10:20:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRWE-0003C2-Nn; Wed, 31 May 2006 10:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRWC-0003Bm-UM for sip@ietf.org; Wed, 31 May 2006 10:17:52 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRWB-0007lO-Ex for sip@ietf.org; Wed, 31 May 2006 10:17:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VEHnH2012705 for ; Wed, 31 May 2006 17:17:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 17:16:54 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 17:16:53 +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: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Date: Wed, 31 May 2006 17:16:53 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F0260098C@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Usage of flows in draft-ietf-sip-outbound-03 Thread-Index: AcaEvN12L0iPv+DwTqOV/C/OidD35w== From: To: X-OriginalArrivalTime: 31 May 2006 14:16:53.0925 (UTC) FILETIME=[DDF61D50:01C684BC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: sip@ietf.org X-Mailman-Version: 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 reading draft-ietf-sip-outbound earlier I got (a wrong) idea that the UA would use those flows it has set up towards the outbound-proxy-set during registration, for sending any other requests thereafter. However this is not the case. When thinking this a bit more I found two use cases and different problem with each of them and I would like to get some answers how the next version of the draft should deal with those: 1. Sending request to first hop other than outbound proxy Sections 4.3.1 and 4.3.2 tell that the "The UA performs normal=20 DNS resolution on the next hop URI (as described in RFC 3263)=20 to find a protocol, IP address, and port." and "If the UA cannot use one of the existing flows, then it SHOULD form a new flow by sending a datagram or opening a new connection to the next hop, as appropriate for the transport protocol." =20 Is the UA expected to keep this new flow alive ? If yes, how long ? I do not think it is a valid requirement for the UA to keep a flow alive forever towards any proxy the UA has communicated with. But the draft does not suggest any rules about when the flow should be closed. For the flow related to registration I believe the flow can be cleared after removing the registration binding, but what about a flow the UA has opened when initiating a call through some other proxy than the outbound proxy e.g. due to 305 response ? 2. Sending registration refreshes I believe that draft-ietf-sip-outbound is written with the assumption that when the UA refreshes a registration binding the REGISTER message would be sent over the same flow over which the binding was created, right ? Or at least that the refreshed REGISTER would reach the same target host (outbound proxy) that received the very first REGISTER request, now to be refreshed ? However this is not guranteed. When sending the REGISTER refresh, the UA is supposed to use DNS procedures of RFC 3263 for resolving the URI of the outbound proxy. While doing that the UA may find a number of SRV records for that URI, having equal priorities and equal or different weights. Basically according to RFC 2782 the UA would select the used SRV record by random, possibly a different target host than the one used previously. Is this a problem for SIP Outbound (while it is not a problem in RFC 3261 point of view)? What happens in this case: - Should the UA keep the flows now alive to those two proxies for the same refreshed registration or should it silently drop the first one ? I believe keeping all those flows open would be an unnecessary burden, especially for mobile devices with a battery. - Is there any risk that a proxy or registrar would try to use=20 such a flow towards the UA that is no more existing ? I would hope the next version of the draft would explicitely specify either that the UA is supposed to use the existing flow instead of=20 performing RFC 3263 processing for the refreshed REGISTER or that the UA should drop the flow it had with the target host it used earlier, when receiving the 200 OK for the REGISTER. Feel free to tell me if I got it wrong at some point. Regards, Erkki Koivusalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 31 10:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRnK-0001sj-3M; Wed, 31 May 2006 10:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRnI-0001m5-Jz for sip@ietf.org; Wed, 31 May 2006 10:35:32 -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 1FlRnI-0000jl-Hv for sip@ietf.org; Wed, 31 May 2006 10:35:32 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlRnG-00008W-Gg for sip@ietf.org; Wed, 31 May 2006 10:35:32 -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.4) with ESMTP id k4VEZNWs043044 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 May 2006 09:35:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <17532.42511.131915.278909@rautu.tutpro.com> References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <17532.42511.131915.278909@rautu.tutpro.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E74F7E2-57E7-4A72-B4EC-383686B2E4DC@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: transport=tls vs 3263 (was Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips) Date: Wed, 31 May 2006 09:35:23 -0500 To: Juha Heinanen X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: -2.6 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Sip , Michael Thomas , "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 Just to be precise - There _is_ a way to tell the next hop to use TLS (or whatever protocol) using 3263, so "next hop" probably isn't the real motivation for the continued existence of transport=tls in the wild. I see four possible motivations for its continued presence: 1) The people using it are just testing things point-to-point in labs and don't want to take on the pain of setting up DNS. (We should recognize this group exists, collectively sigh, then move on). 2) The elements using it are endpoints with ephemeral addresses, but want incoming connections to come over TLS. They have certificates such that an incoming TLS connection makes sense, and no NAT/FW policies that prevent a TCP connection attempt from reaching them in the first place, but they have no name in DNS that they can add RRs for. (Some have argued that this is fringe, and an unrealistic case to design around. The P2P folks, for example, probably disagree). 3) The designers of the application using it do not agree with the assumptions and constraints placed on transport selection in 3263. The model in that document assumes that the preference for transport coming into an element is constant across all resources. It does not allow us, for example, to indicate preference for TLS for one set of usernames but UDP for another. 4) The designers of the network using it refuse to use DNS in that network at all (but still want TLS...) Are there other motivations that I've missed? RjS On May 30, 2006, at 3:07 PM, Juha Heinanen wrote: > Vijay K. Gurbani writes: > >> A couple more: sips provides confidentiality of traffic >> and authentication of a proxy and registrar to a UAC. Admittedly, >> one could do this with transport=tls, but this particular >> construct is deprecated in rfc3261. > > transport=tls is used in practise, because no other ways exist to tell > that tls is to be used on the next hop. there is thus still need > for it > and sips is not a replacement due to its end-to-end nature. > > -- 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 Wed May 31 10:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRto-0005iW-7U; Wed, 31 May 2006 10:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlRtm-0005iQ-Il for sip@ietf.org; Wed, 31 May 2006 10:42:14 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRti-0001GG-Ub for sip@ietf.org; Wed, 31 May 2006 10:42:14 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 07:42:10 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="1816305603:sNHT35218620" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VEg9le028778; Wed, 31 May 2006 07:42:09 -0700 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 k4VEg9Iu004993; Wed, 31 May 2006 10:42:09 -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.211); Wed, 31 May 2006 10:42:09 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 10:42:08 -0400 Message-ID: <447DAB40.4050609@cisco.com> Date: Wed, 31 May 2006 10:42:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Dean Willis Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <447CCACA.10501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2006 14:42:08.0691 (UTC) FILETIME=[64D51030:01C684C0] DKIM-Signature: a=rsa-sha1; q=dns; l=5105; t=1149086529; x=1149950529; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=09draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DzGRi8FcjGKHlSkY4tQGcXxUA9VA=3D; b=PUDdGWZxN1xvL+WrXGMH2P3tsWQlpWkYIeizApkVkeVtuLPn3Y+dXXb+rCHX9f7AXuTLso67 FHIeh65MlHMZKJPkBN9l9wT57IY2nw6O3DlE2wI2GjVCUjsqqsxqOH+I; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Sip , Michael Thomas , "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 Dean, I really like your characterization of the alternatives here! More below. Paul Dean Willis wrote: > > On May 30, 2006, at 5:44 PM, Michael Thomas wrote: >>> >>> Dean has pointed out one answer to this; namely, "reduces the >>> probability of an accidental downgrade by intermediate proxies >>> between the UAC and the proxy responsible for the AOR, if those >>> proxies bother to honor it." >> >> >> How does it do that? Why does this sort of behavior require an ill >> conceived protocol element when it is really a BCP in disguise? >> > > Because we operate with the presumptions that 1 ) most people don't want > security, and 2) proxies will be extremely careless with our data unless > we politely ask them not to. Further, we want to tell the proxies that > if they aren't willing to be careful with our data, we'd rather they > tell us up front so we can take our data elsewhere. > > Therefore, we need a protocol element to be able to ask the proxy to do > what was probably "the right thing" all along. > >>> To other services such as transporting presence, sips provides >>> confidentiality. The semantics of transport=tls, if un-deprecated >>> would be limited to next hop only; the semantics of sips -- if we >>> tighten the spec up appropriately -- are confidentiality across >>> all participating hops. >> >> >> No. That is simply incorrect, and why this is so deeply problematic. >> And it leaves people with the mistaken impression that there is >> https style security when there is absolutely no way to test or >> count on that. > > Well, it sort of provides confidentiality, except to the proxies, as > long as the proxies really are as careful with our data as we asked them > to be which they may or may not be and we have no way of verifying. > Sometimes, as Cullen has pointed out, this is good enough, or at least > enough better than nothing that it is worth having. > > Ok, I am failing to reassure myself here. > > > I'm detecting five different use cases that people are asking for: > > 1) I don't care about security, just make it work. > > 2) Use as much security as you can, but I'm willing to accept downgrades > without being informed if you must. > > 3) I want hop-by-hop security that provides protections roughly > equivalent to TLS if it were used on a hop-by-hop basis, and I want my > request aborted and to be informed on it if you can't make that happen. > > 4) I want hop-by-hop protection using TLS, and I want my request aborted > and to be informed on it if you can't make that happen. > > 5) I want my signaling locked-down end-to-end, and insist on being able > to verify that this is the case. And if we exchange media, I want that > locked-down too, and I want to be able to verify that too. > > > Right now, I think we're arguing about a) whether sips: means case 2, 3, > or 4. b) If sips: doesn't include case 2, do we need another mechanism > for that, and 3) whether any of case 2, 3, or 4 are really useful. > > Personally I see some value in cases 2 and 3, none in case 4 that isn't > achieved by 3, and a whole lot more in the currently unobtainable case > 5, for which Vijay has proposed the new URI class "sipsec:" Of these, I find only 1,3,5 to be at all interesting. Of those, I think 3 falls in the same pot as all the transitive trust "features" such as P-Asserted-ID, and probably makes sense in those environments. Its better than nothing if you have a service provider you are willing to trust, and it is probably the best we are going to get from a lot of service providers. I would much rather have 5 than 3, but: - its not at all clear to me that we know how to provide it in a practical way - I think a lot of major operators would not wish to provide this unless forced. (either by laws or competitive pressures.) - if there is any law on this subject, it would probably be to ban 5 rather than to require it. :-( > 3261, oddly enough, doesn't address any of these use cases. Rather, it > says "I want hop-by-hop protection using TLS as far as the proxy > corresponding to the request-URI, and and I want my request aborted and > to be informed on it if you can't make that happen. After the request > has reached the node corresponding to the request-URI, I want as much > security as possible, but leave the selection and application of that > security in the hands of the callee and its supporting nodes. If the > callee didn't register with a sips: contact or happens to be a PSTN > gateway, I still want the call to go through, and I don't need to be > notified about the change in the security envelope. > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 31 11:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAq-0004Tv-Fl; Wed, 31 May 2006 10:59:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAm-0004S3-MI for sip@ietf.org; Wed, 31 May 2006 10:59:48 -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 1FlS0j-0002NO-Um for sip@ietf.org; Wed, 31 May 2006 10:49:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 31 May 2006 07:49:25 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="323882224:sNHT34648512" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4VEnOTb025514; Wed, 31 May 2006 07:49:25 -0700 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 k4VEnOkw027082; Wed, 31 May 2006 10: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.211); Wed, 31 May 2006 10:49:24 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 10:49:24 -0400 Message-ID: <447DACF3.3020002@cisco.com> Date: Wed, 31 May 2006 10:49:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Dean Willis Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2006 14:49:24.0294 (UTC) FILETIME=[6878CE60:01C684C1] DKIM-Signature: a=rsa-sha1; q=dns; l=4390; t=1149086965; x=1149950965; c=relaxed/simple; s=sjdkim3001; 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=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=09draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3DQrxnAhwSWMi3d2Ti/W213iaMRLQ=3D; b=jrR8jLaxIXpz9lspTTf/EtES7n3d6U3ZS0TA7/inoSi7wzSPvE8zq7oYwuVv3KkVy5Ur0GEp aZkw/v9kmMqaXvbS2LH6Ws2+3WC1ThVL4+ovmjOAVqmxHnSnnq3assy+; Authentication-Results: sj-dkim-3.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Cullen Jennings , Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean - you were on a roll yesterday. Again I violently agree. Perhaps we need both SIPS and Proxy-Require:link-security. Then the meaning of sips could be simplified. The sips is an indication of the target's expectation, while the Proxy-Require is the caller's expectation. The first node to place a sips URI into the R-URI would also add the Proxy-Require, in order to honor the target's desires. Proxies otherwise would simply honor the Proxy-Require. But the Proxy-Require could also be used with tel or sip if that is what the caller desires. Paul Dean Willis wrote: > > On May 30, 2006, at 12:02 AM, Cullen Jennings wrote: >> >> I think that at the high level, the semantics of sips are simple. We >> want it to mean that every hop from the UAC to the UAS was integrity >> and confidentiality protected at a reasonable level assuming >> transitive trust. This can be very useful. At the more fine details >> level, we have some parts that are unclear in how to implement it, we >> probably have some bugs in the spec, and perhaps we even one place >> where we made a bad choice that we may correct. I'm very keen on this >> draft - I want it to try and sort out the details that are missing or >> wrong. >> > > > "Correcting" the "bad choice" in the proposed way would be counter to > the semantics you give above. > > It's been proposed that we should change RFC 3261 to require that, if > sips: is used, then TLS MUST be used on all hops. This runs afoul of > architectures where some other mechanism, notably IPSEC, is used on some > hops. > > If we make this proposal a requirement, we end up in in a situation > where we frequently cannot use sips: on the UAC to serving-proxy hops > because some other security mechanism is used on the back side of the > serving proxy. And since sips: is the only "please secure me" indicator > we have, this means that we have no way to request any security > treatment at all in this situation -- in short, that we're requiring > people to NOT secure some links. > > This doesn't sound particularly rational. > > Perhaps what you really want is a rule more like "Proxies MUST NOT > forward requests with a sips: URI onto links lacking reasonable > integrity or confidentiality mechanisms. An example of a reasonable > mechanism would be TLSThis would be roughly equivalent to a > "Proxy-Require: link-security" option mechanism that I recall someone > else proposing. > > This would actually benefit deployability, since it would also allow > using sips: on calls from UACs that are using non-TLS (but secure) links > to their proxies, whereas RFC 3261 as-is allows it only in the other > direction. > > Now, let's consider retargeting -- the thing that serving proxies do > when they replace a request-URI with a URI that was registered as a > contact. It has been proposed that we adopt the rule "Proxies that > retarget (change the request-URI) MUST NOT retarget a request that was > originally targeted to a sips: URI to any other URI type." Well, that > sort of does in forwarding your calls to a tel: URI while still getting > the exposed SIP links protected. We could perhaps live with that, but it > does seem to be a waste. Here at least we could get more mileage out of > a proxy-require option tag that requires the resulting tel: request to > traverse only secure links. > > > But in any case, sips: remains only a marginal indicator of security. > It's kind of like a note by the door of the office that says "Last one > out, please lock the door". If somebody forgets, or choses not to, the > door isn't locked, and nobody else knows. It's not the lack of security > that gets me -- it's the lack of KNOWING that there is no security. Our > current usage of sips: is no more secure and generally applicable to the > Internet than the trust-domain protections around the privacy of > P-Asserted-Identity are, and we made that a P-header. > > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 31 11:06:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSFI-0005Mq-IX; Wed, 31 May 2006 11:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSFH-0005Mj-Hd for sip@ietf.org; Wed, 31 May 2006 11:04:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSFG-0005hK-3e for sip@ietf.org; Wed, 31 May 2006 11:04:27 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 08:04:19 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="286131930:sNHT12765971264" 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/8.12.11) with ESMTP id k4VF4J3d007770; Wed, 31 May 2006 08:04:19 -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 k4VF47J4004584; Wed, 31 May 2006 08:04:19 -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.211); Wed, 31 May 2006 11:04:19 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 11:04:18 -0400 Message-ID: <447DB072.8000304@cisco.com> Date: Wed, 31 May 2006 11:04:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: AW: [Sip] Connected-identity and changing the To header field ina response References: <85108216918A984C8C60172D7C84770A08A50F@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <85108216918A984C8C60172D7C84770A08A50F@S4DE8PSAAGO.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 31 May 2006 15:04:18.0539 (UTC) FILETIME=[7D7BC3B0:01C684C3] DKIM-Signature: a=rsa-sha1; q=dns; l=2603; t=1149087859; x=1149951859; c=relaxed/simple; s=sjdkim6001; 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=20AW=3A=20[Sip]=20Connected-identity=20and=20changing=20the=20To=2 0header=20field=0A=20ina=09response; X=v=3Dcisco.com=3B=20h=3D3BSMIBKxWRjq+6dwJo3shWFW+lY=3D; b=PSlMHbfeVPo7wl1xjvXsquCSwpYvpQft7kbp6lATAYgEmYEHk62xXd56A8TfE9ZXT6oa0EeQ jhkN+XkAjmWRZ4VTu4F4FQMHfYm+GepnizDOcni5Ge6/1CKwzNv9rhtP; 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: e8a67952aa972b528dd04570d58ad8fe Cc: fluffy@cisco.com, sip@ietf.org, john.elwell@siemens.com, roland.jesske@web.de, christer.holmberg@ericsson.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 Jesske, R wrote: > These are the requirements we already expressed in our draft draft-jesske-sipping-tispan-requirements-02: > > REQ-TIP-1: In addition to any network asserted identity, it must be > possible for the callee to indicate in a SIP response an > additional identity where the user is reachable for future > direct communications. Note that the requirement refers > to the user, not to the same instance of the User Agent. > REQ-TIP-2: The identity mentioned in REQ-TIP-1 must be formatted as a > SIP URI [2] or TEL URL [3]. A translation between SIP URI > and TEL URL by the network is not requested. > REQ-TIP-3: The identity mentioned in REQ-TIP-1 is considered an end > user supplied information that is not asserted by the > network. > > > As you can see we do not need any authenticated identity in the response. For the authenticated identity we are using the P-Asserted-Identity. So we have two identities in a Response. > For our purposes the user provided identity in a final 200 OK response is sufficient. So that avoids confusion within forking cases. I haven't been paying close attention to this. What header are you planning to use to carry this callee provided identity? The Reply-To header would seem to be appropriate for this purpose, but unfortunately, according to table 2 of 3261, it is only allowed in INVITE. Paul > Roland > > > > >> -----Ursprüngliche Nachricht----- >> Von: Cullen Jennings [mailto:fluffy@cisco.com] >> Gesendet: Montag, 22. Mai 2006 17:32 >> An: Jesske, Roland >> Cc: John Elwell; sip@ietf.org; Roland Jesske; Christer >> Holmberg (JO/LMF) >> Betreff: Re: [Sip] Connected-identity and changing the To >> header field ina response >> >> >> >> On May 16, 2006, at 7:07 AM, Jesske, R wrote: >> >>> John, >>> it is that we don't can get an connected identity within the final >>> response of the initial INVITE. >>> Your draft proposes a mid dialog request for getting this >> information. >>> That is not usable for the TIP service. >> I think this is part of what I am not understanding. What is the >> requirement here? >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 31 11:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSQ6-0002mb-6e; Wed, 31 May 2006 11:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSQ5-0002jl-E6 for sip@ietf.org; Wed, 31 May 2006 11:15:37 -0400 Received: from imagespc.com ([216.18.74.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlSQ3-0007fu-3s for sip@ietf.org; Wed, 31 May 2006 11:15:37 -0400 Received: from charles ([209.71.241.13]) by imagespc.com (imagespc.com) (MDaemon.PRO.v8.0.3.R) with ESMTP id md50001002057.msg for ; Wed, 31 May 2006 11:16:07 -0400 From: "Charles Abondo" To: "'Sip'" Date: Wed, 31 May 2006 11:14:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <447DACF3.3020002@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcaEw0bs5+BGG3AtSZ63seG+gwxlEwAAK7kA X-Spam-Processed: imagespc.com, Wed, 31 May 2006 11:16:07 -0400 (not processed: message from valid local sender) X-MDRemoteIP: 209.71.241.13 X-Return-Path: charles@blueslice.com X-MDaemon-Deliver-To: sip@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] Options method and Authorization field X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Message-Id: Hi, I need help on those topics: 1. May I support Options method without supporting any Invite? This means answering Options request with 200 OK even if I am a Registrar for example. 2. May I have received as a UAS (last hop on a path) a Request with several Authorisation fields (there is no Sip capable entity after the UAS? If yes, how do I select one (realm ....)? Any help will be appreciated, Regards, Charles Abondo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 31 11:18:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSRc-0002w3-JW; Wed, 31 May 2006 11:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSRb-0002vy-LL for sip@ietf.org; Wed, 31 May 2006 11:17:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRSI-0007Yr-Ur for sip@ietf.org; Wed, 31 May 2006 10:13:50 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlR8h-0007rZ-80 for sip@ietf.org; Wed, 31 May 2006 09:53:35 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id B0E786C017 for ; Wed, 31 May 2006 09:53:34 -0400 (EDT) Subject: RE: [Sip] "backup" outbound flows From: "Dale R. Worley" To: Sip In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> Content-Type: text/plain Date: Wed, 31 May 2006 09:53:34 -0400 Message-Id: <1149083614.458.3.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) 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 On Wed, 2006-05-31 at 16:36 +0300, Erkki.Koivusalo@nokia.com wrote: > So putting the issue together: if the NAT / firewall traversal > is the key issue for draft-ietf-sip-outbound-03, does introduction > of multiple redundant flows actually increase the likelihood of > having a flow alive so much that it is worth the effort and > additional traffic for keepalives ? Well, that's a different problem than the one I was asking about -- namely, is it worth the effort to *maintain* two flows? One could establish a backup flow at the time that one discovers that the primary flow has failed. (Which has the advantage that one can with certainly choose a proxy that is working at the moment of need.) The only disadvantage is that it takes time to establish the second flow. The only reason that one would want to have the backup flow pre-established is that the setup time is longer than can be tolerated. But I've never seen anyone say that they've determined that the setup time is too long to be tolerated. I've never even seen anyone *assert* (with or without evidence) that the setup time is too long. We just seem to be progressing with the design, taking that for granted. 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 May 31 13:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUuL-0003yo-E2; Wed, 31 May 2006 13:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlUuJ-0003x5-Mb for sip@ietf.org; Wed, 31 May 2006 13:54:59 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlUqg-0005Ht-VT for sip@ietf.org; Wed, 31 May 2006 13:51:18 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4VHp8x19941; Wed, 31 May 2006 12:51:08 -0500 Date: Wed, 31 May 2006 12:51:08 -0500 Message-Id: <200605311751.k4VHp8x19941@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Sip , Michael Thomas Subject: [Sip] Re: Wacky thead of the month award goes to ... Re: X-BeenThere: sip@ietf.org X-Mailman-Version: 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 there is any law on this subject, it would probably be to > ban 5 rather than to require it. :-( > I think it's incumbent upon us to test that theory. 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 Wed May 31 14:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV5R-0001Fm-Df; Wed, 31 May 2006 14:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlV5Q-0001Ff-JH for sip@ietf.org; Wed, 31 May 2006 14:06:28 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlV5O-0006GN-7I for sip@ietf.org; Wed, 31 May 2006 14:06:28 -0400 Received: by tutpro.com (Postfix, from userid 65534) id 3CB8613F8AE; Wed, 31 May 2006 21:06:25 +0300 (EEST) Received: from rautu (in-vitro36.gprs.dnafinland.fi [62.78.121.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tutpro.com (Postfix) with ESMTP id 4CDEB13F8AD; Wed, 31 May 2006 21:06:14 +0300 (EEST) Received: by rautu (Postfix, from userid 1000) id F0643F03C1; Wed, 31 May 2006 18:10:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17533.45513.595986.235971@rautu.tutpro.com> Date: Wed, 31 May 2006 18:10:01 +0300 From: Juha Heinanen To: Subject: RE: [Sip] "backup" outbound flows In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> References: <1149005278.5457.15.camel@niagra.pingtel.com> <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on lohi.tutpro.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Erkki.Koivusalo@nokia.com writes: > So putting the issue together: if the NAT / firewall traversal > is the key issue for draft-ietf-sip-outbound-03, does introduction > of multiple redundant flows actually increase the likelihood of > having a flow alive so much that it is worth the effort and > additional traffic for keepalives ? erkki, if UA has flow open to multiple proxies, then any of these proxies may send request to the UA, which makes load balancing of proxies possible. seems like you forgot that important aspect. > With only two flows (one primary and one backup) it is impossible > to reach both those aims simultaneously, regardless of whether those > two target hosts are determined by UA configuration or DNS queries. could you please stop mentioning primary and backup, since that kind of distinction should go away from outbound i-d. -- 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 Wed May 31 14:40:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVZZ-0006e6-PZ; Wed, 31 May 2006 14:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlVZZ-0006bU-7v for sip@ietf.org; Wed, 31 May 2006 14:37:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlVZU-0000ch-V7 for sip@ietf.org; Wed, 31 May 2006 14:37:35 -0400 Received: from [192.168.2.103] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4VIcToI013197 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 May 2006 13:38:30 -0500 In-Reply-To: <200605311751.k4VHp8x19941@smapp01.siteprotect.com> References: <200605311751.k4VHp8x19941@smapp01.siteprotect.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 31 May 2006 13:37:08 -0500 To: fwmiller@cornfed.com X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Sip , Paul Kyzivat , Michael Thomas Subject: [Sip] Re: Wacky thead of the month award goes to ... Re: X-BeenThere: sip@ietf.org X-Mailman-Version: 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 May 31, 2006, at 12:51 PM, fwmiller@cornfed.com wrote: > > >> - if there is any law on this subject, it would probably be to >> ban 5 rather than to require it. :-( >> > > I think it's incumbent upon us to test that theory. > Yes! -- 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 May 31 15:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWP3-00081X-Pk; Wed, 31 May 2006 15:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWP2-0007zS-8E for sip@ietf.org; Wed, 31 May 2006 15:30:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWP0-0006eR-TJ for sip@ietf.org; Wed, 31 May 2006 15:30:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 31 May 2006 12:30:46 -0700 X-IronPort-AV: i="4.05,194,1146466800"; d="scan'208"; a="1816533530:sNHT35147928" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VJUjZf019890; Wed, 31 May 2006 12:30:45 -0700 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 k4VJUjku004280; Wed, 31 May 2006 15:30: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.211); Wed, 31 May 2006 15:30:45 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 15:30:44 -0400 Message-ID: <447DEEE4.4060006@cisco.com> Date: Wed, 31 May 2006 15:30:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Dale R. Worley" Subject: Re: [Sip] "backup" outbound flows References: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> <1149083614.458.3.camel@niagra.pingtel.com> In-Reply-To: <1149083614.458.3.camel@niagra.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2006 19:30:44.0905 (UTC) FILETIME=[B619A190:01C684E8] DKIM-Signature: a=rsa-sha1; q=dns; l=2441; t=1149103845; x=1149967845; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Sip]=20=22backup=22=20outbound=20flows; X=v=3Dcisco.com=3B=20h=3DVTh67Em68lUo/tnPbY6xTFzNS7o=3D; b=gxFP8ZkaLVVSc6ATNG4ga8m9Aqnfky7MBRt28AMViX77yzScM/HiWaAd0lXwOvpKNYVZslBt yKcHog8dmvJLJeCs7X9o+Meu+wm8egOElUSFcN/8GVt66FMBlTNR7kBl; Authentication-Results: sj-dkim-1.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 don't know what "too long" is. But this is one of those places where avalanche restart is a problem. E.g. the proxy serving Manhattan goes down and everybody reregisters to the alternate proxy in Hoboken. To avoid killing the backup, you want to randomize the time when the reregistration is attempted. But if in the meantime you have no connection at all, then you miss calls. But if you normally have two connections, then when one of them goes down you can take your time getting a replacement for it established. E.g. you have connections to Manhattan and Hoboken. Then you notice your Manhattan connection has gone away. So at your leisure you try to reconnect to another server, say in Queens. Its ok if it takes 5/10/15/30 minutes, because meanwhile you can still get calls via Hoboken. Paul Dale R. Worley wrote: > On Wed, 2006-05-31 at 16:36 +0300, Erkki.Koivusalo@nokia.com wrote: >> So putting the issue together: if the NAT / firewall traversal >> is the key issue for draft-ietf-sip-outbound-03, does introduction >> of multiple redundant flows actually increase the likelihood of >> having a flow alive so much that it is worth the effort and >> additional traffic for keepalives ? > > Well, that's a different problem than the one I was asking about -- > namely, is it worth the effort to *maintain* two flows? One could > establish a backup flow at the time that one discovers that the primary > flow has failed. (Which has the advantage that one can with certainly > choose a proxy that is working at the moment of need.) The only > disadvantage is that it takes time to establish the second flow. The > only reason that one would want to have the backup flow pre-established > is that the setup time is longer than can be tolerated. > > But I've never seen anyone say that they've determined that the setup > time is too long to be tolerated. I've never even seen anyone *assert* > (with or without evidence) that the setup time is too long. We just > seem to be progressing with the design, taking that for granted. > > 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 Wed May 31 15:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWWu-0003Gs-5L; Wed, 31 May 2006 15:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWWs-0003Gn-5U for sip@ietf.org; Wed, 31 May 2006 15:38:54 -0400 Received: from [66.113.136.12] (helo=smapp01.siteprotect.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWWq-0007Jl-TW for sip@ietf.org; Wed, 31 May 2006 15:38:54 -0400 Received: from smapp01.siteprotect.com (localhost [127.0.0.1]) by smapp01.siteprotect.com (8.11.6/8.11.6) with ESMTP id k4VJcox30249; Wed, 31 May 2006 14:38:50 -0500 Date: Wed, 31 May 2006 14:38:50 -0500 Message-Id: <200605311938.k4VJcox30249@smapp01.siteprotect.com> From: fwmiller@cornfed.com To: "Dean Willis" , fwmiller@cornfed.com Subject: End-to-end security (was RE: [Sip] Re: Wacky thead... X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Thinking a bit more about this end-to-end thing, I thought I would float an idea that has probably been proposed before... First, it seems like the interposition of proxies as a basic architectural element is a non-starter. What I mean is, if there are proxies in there somewhere, you can probably make an argument that the proxy could be compromised. If the signaling has to pass through the proxy, you cannot guarantee end-to-end security. If you grant that, then an INVITE must go from the UAC to the UAS directly. The question is, how do you make that happen? How do you guarantee to the caller that the INVITE is not traversing any proxies along the way? I'm wondering if there can't be some kind of end-to-end mode for signaling? Let's say that a UAC wants to make an end-to-end secure call to an UAS. Perhaps the UAC could query a presence service for the actual endpoint address of the UAS. Perhaps we could add some presence bits that tell the presence server that a UAS is at this address for direct access and then when the UAC queries for the UAS, it gets that address. If this were done, the trust would be changed to trusting the UAS and the presence server. Is that better than trusting the proxies during hop-by-hop signaling? 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 Wed May 31 15:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWm2-0002bM-0i; Wed, 31 May 2006 15:54:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWm0-0002bG-HW for sip@ietf.org; Wed, 31 May 2006 15:54:32 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWlz-0000rl-BT for sip@ietf.org; Wed, 31 May 2006 15:54:32 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 028566C01C for ; Wed, 31 May 2006 15:54:21 -0400 (EDT) Subject: Re: End-to-end security (was RE: [Sip] Re: Wacky thead... From: "Dale R. Worley" To: Sip In-Reply-To: <200605311938.k4VJcox30249@smapp01.siteprotect.com> References: <200605311938.k4VJcox30249@smapp01.siteprotect.com> Content-Type: text/plain Date: Wed, 31 May 2006 15:54:20 -0400 Message-Id: <1149105260.458.24.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sip@ietf.org X-Mailman-Version: 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's nearly pointless to try to keep signaling confidential. The packets have to go from the UAC to the UAS, and anybody who cuts into the wire can watch that. There is some advantage to avoiding forwarding the INVITE through proxies, as the proxies become targets for *concentrated* attack. But that's not much. Conversely, if you eliminate the proxies, the UAC must know the IP address of the UAS de novo. (If it knew only the DNS name, the DNS server would be a point of attack.) The best you can do is about what current security proposals allow -- a not particularly secure means for putting the UAC and UAS into contact. After that, they can validate their identities to each other securely, and exchange media securely. 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 May 31 16:22:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXAW-0007Go-5K; Wed, 31 May 2006 16:19:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXAU-0007Gh-R3 for sip@ietf.org; Wed, 31 May 2006 16:19:50 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlXAS-0003Xj-DC for sip@ietf.org; Wed, 31 May 2006 16:19:50 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1149106327!9421356!14 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 30964 invoked from network); 31 May 2006 20:13:08 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 31 May 2006 20:13:08 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F00054B8C; Wed, 31 May 2006 16:13:07 -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: End-to-end security (was RE: [Sip] Re: Wacky thead... Date: Wed, 31 May 2006 15:13:07 -0500 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C7B7@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <200605311938.k4VJcox30249@smapp01.siteprotect.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End-to-end security (was RE: [Sip] Re: Wacky thead... Thread-Index: AcaE6lHP21DfA7a7SyyXbOjdkkpnWgABDASw From: "Dolly, Martin C, ALABS" To: , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 The hop-by-hop method needs to be supported, not just with proxies but B2BUAs.=20 -----Original Message----- From: fwmiller@cornfed.com [mailto:fwmiller@cornfed.com]=20 Sent: Wednesday, May 31, 2006 3:39 PM To: Dean Willis; fwmiller@cornfed.com Cc: Sip; Paul Kyzivat Subject: End-to-end security (was RE: [Sip] Re: Wacky thead... Thinking a bit more about this end-to-end thing, I thought I would float an idea that has probably been proposed before... First, it seems like the interposition of proxies as a basic architectural element is a non-starter. What I mean is, if there are proxies in there somewhere, you can probably make an argument that the proxy could be compromised. If the signaling has to pass through the proxy, you cannot guarantee end-to-end security. If you grant that, then an INVITE must go from the UAC to the UAS directly. The question is, how do you make that happen? How do you guarantee to the caller that the INVITE is not traversing any proxies along the way? I'm wondering if there can't be some kind of end-to-end mode for signaling? Let's say that a UAC wants to make an end-to-end secure call to an UAS. Perhaps the UAC could query a presence service for the actual endpoint address of the UAS. Perhaps we could add some presence bits that tell the presence server that a UAS is at this address for direct access and then when the UAC queries for the UAS, it gets that address. If this were done, the trust would be changed to trusting the UAS and the presence server. Is that better than trusting the proxies during hop-by-hop signaling? FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 31 17:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXs8-00057E-VG; Wed, 31 May 2006 17:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXs7-000579-Lb for sip@ietf.org; Wed, 31 May 2006 17:04:55 -0400 Received: from mail.pingtel.com ([65.220.123.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlXs4-0000JJ-F8 for sip@ietf.org; Wed, 31 May 2006 17:04:55 -0400 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 2030F6C01C for ; Wed, 31 May 2006 17:04:52 -0400 (EDT) Subject: Re: [Sip] "backup" outbound flows From: "Dale R. Worley" To: Sip In-Reply-To: <447DEEE4.4060006@cisco.com> References: <8B1D53AEF7B03449A6D3771B3B7F850F02600951@esebe103.NOE.Nokia.com> <1149083614.458.3.camel@niagra.pingtel.com> <447DEEE4.4060006@cisco.com> Content-Type: text/plain Date: Wed, 31 May 2006 17:04:51 -0400 Message-Id: <1149109491.458.32.camel@niagra.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 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-05-31 at 15:30 -0400, Paul Kyzivat wrote: > I don't know what "too long" is. But this is one of those places where > avalanche restart is a problem. E.g. the proxy serving Manhattan goes > down and everybody reregisters to the alternate proxy in Hoboken. OK, now I understand. Thanks, 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 May 31 19:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZtP-0002Jt-Dy; Wed, 31 May 2006 19:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZtN-0002Jo-Sl for sip@ietf.org; Wed, 31 May 2006 19:14:21 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZtM-0007iG-Ld for sip@ietf.org; Wed, 31 May 2006 19:14:21 -0400 Received: by py-out-1112.google.com with SMTP id i75so121130pye for ; Wed, 31 May 2006 16:14: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=SHuBUB29Uu/WnHAFknb5Kb4kgffCcBvhijU6pjOn28dgIei4DYtDlE2YWl/tC5nm4Wj2Wrspzyxa3ZTutuRcrxNMS2xKvsmwm5Pajw1VzMThPIA3SQP8QPfhL8dYxNbZgZVFGA5u9gJEzjEHXWhX+ncse1yJBjciWOFA2pbYX1I= Received: by 10.35.123.2 with SMTP id a2mr847460pyn; Wed, 31 May 2006 16:14:20 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Wed, 31 May 2006 16:14:19 -0700 (PDT) Message-ID: <953beacc0605311614g40618ac8n6ca6ab25069fd419@mail.gmail.com> Date: Wed, 31 May 2006 16:14:19 -0700 From: "Rohan Mahy" To: "Michael Thomas" Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <447CCACA.10501@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <447CCACA.10501@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Sip , "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 Michael, You seem to have a mistaken impression that transport=tls means something it does not/is actually useful. Unfortunately, transport=tls only affects the next hop, it interferes with NAPTR selection of the actual underlying transport (TCP, UDP, SCTP, DCCP), it looks really ugly in URIs, and it is a pain in the arse to enter on a phone keypad. I don't really believe the last two are a big deal, but the important thing here is that sips: has the semantics that most folks think transport=tls should have, but transport=tls actually does not have. thanks, -rohan On 5/30/06, Michael Thomas wrote: > Vijay K. Gurbani wrote: > > > Michael Thomas wrote: > > > >> My question is whether it's answer to _any_ problem. My last attempt at > >> getting and answer was fruitless. What attacks do SIPS thwart in real > >> life > >> that honest operators and transport=tls doesn't? Real life good guy, > >> bad guy situations would be helpful. > > > > > > Sorry -- catching up after a forced, and not entirely un-welcome, > > lull introduced by the weekend. > > > > Dean has pointed out one answer to this; namely, "reduces the > > probability of an accidental downgrade by intermediate proxies > > between the UAC and the proxy responsible for the AOR, if those > > proxies bother to honor it." > > > How does it do that? Why does this sort of behavior require an ill > conceived protocol element when it is really a BCP in disguise? > > > > > A couple more: sips provides confidentiality of traffic > > and authentication of a proxy and registrar to a UAC. Admittedly, > > one could do this with transport=tls, but this particular > > construct is deprecated in rfc3261. Currently, there is no means > > for a UAC to authenticate a registrar or a proxy; sips at the > > very least, allows for the signaling between the UAC and a > > registrar to be on an confidential and authenticated channel. > > > So SIPS is overloaded with transport=tls; Bletch. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.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 May 31 19:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZv4-0003Uj-St; Wed, 31 May 2006 19:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZv2-0003Ub-Rm for sip@ietf.org; Wed, 31 May 2006 19:16:04 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZv1-0007ll-Kn for sip@ietf.org; Wed, 31 May 2006 19:16:04 -0400 Received: by py-out-1112.google.com with SMTP id c31so114461pyd for ; Wed, 31 May 2006 16:16:03 -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=RkLNrqk+eEC0HK0f/WHaHOoA9GSLPeVRFIYPXrdiXNGUvKc4k5pyXpWmvuOVpj3d6EH+uNOofQUwYbwQguSalowa6GnYhph2HsbKXAB6TBkSqeHHylWMC8HReqqsHjMUS0tuX1cOInjTDGMmyMVDjaM6l806N/8DJ6mKjtekL2Q= Received: by 10.35.22.17 with SMTP id z17mr842580pyi; Wed, 31 May 2006 16:16:03 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Wed, 31 May 2006 16:16:03 -0700 (PDT) Message-ID: <953beacc0605311616j241bcdacy22ffca7ae712636d@mail.gmail.com> Date: Wed, 31 May 2006 16:16:03 -0700 From: "Rohan Mahy" To: "Juha Heinanen" Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips In-Reply-To: <17532.42511.131915.278909@rautu.tutpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <17532.42511.131915.278909@rautu.tutpro.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Sip , Michael Thomas , "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 the contrary Juha, the SIP server role can indicate it wants to the client to use TLS by including the appropriate NATPR and/or SRV records. thanks, -rohan On 5/30/06, Juha Heinanen wrote: > Vijay K. Gurbani writes: > > > A couple more: sips provides confidentiality of traffic > > and authentication of a proxy and registrar to a UAC. Admittedly, > > one could do this with transport=tls, but this particular > > construct is deprecated in rfc3261. > > transport=tls is used in practise, because no other ways exist to tell > that tls is to be used on the next hop. there is thus still need for it > and sips is not a replacement due to its end-to-end nature. > > -- 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 Wed May 31 19:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fla69-0000o0-TM; Wed, 31 May 2006 19:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fla67-0000nu-PZ for sip@ietf.org; Wed, 31 May 2006 19:27:31 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fla67-00080z-Cf for sip@ietf.org; Wed, 31 May 2006 19:27:31 -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 k4VNRR401778; Wed, 31 May 2006 19:27:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Wacky thead of the month award goes to ... Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 18:27:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A2346E3@zrc2hxm0.corp.nortel.com> In-Reply-To: <447DAB40.4050609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaEwOV5ZtJvb/xcQgmBOAYnqgGrHwASLstA From: "Francois Audet" To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Sip , Michael Thomas , "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 I like it too, but I prefer 4 to 3, because 3 is too fuzzy to me, and it has been a source of confusion to many. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, May 31, 2006 07:42 > To: Dean Willis > Cc: Sip; Michael Thomas; Vijay K. Gurbani > Subject: Re: Wacky thead of the month award goes to ...=20 > Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 > Dean, >=20 > I really like your characterization of the alternatives here! >=20 > More below. >=20 > Paul >=20 > Dean Willis wrote: > >=20 > > On May 30, 2006, at 5:44 PM, Michael Thomas wrote: > >>> > >>> Dean has pointed out one answer to this; namely, "reduces the=20 > >>> probability of an accidental downgrade by intermediate proxies=20 > >>> between the UAC and the proxy responsible for the AOR, if those=20 > >>> proxies bother to honor it." > >> > >> > >> How does it do that? Why does this sort of behavior require an ill=20 > >> conceived protocol element when it is really a BCP in disguise? > >> > >=20 > > Because we operate with the presumptions that 1 ) most people don't=20 > > want > > security, and 2) proxies will be extremely careless with=20 > our data unless=20 > > we politely ask them not to. Further, we want to tell the=20 > proxies that=20 > > if they aren't willing to be careful with our data, we'd=20 > rather they=20 > > tell us up front so we can take our data elsewhere. > >=20 > > Therefore, we need a protocol element to be able to ask the=20 > proxy to=20 > > do > > what was probably "the right thing" all along. > >=20 > >>> To other services such as transporting presence, sips provides=20 > >>> confidentiality. The semantics of transport=3Dtls, if=20 > un-deprecated=20 > >>> would be limited to next hop only; the semantics of sips -- if we=20 > >>> tighten the spec up appropriately -- are confidentiality=20 > across all=20 > >>> participating hops. > >> > >> > >> No. That is simply incorrect, and why this is so deeply=20 > problematic.=20 > >> And it leaves people with the mistaken impression that=20 > there is https=20 > >> style security when there is absolutely no way to test or count on=20 > >> that. > >=20 > > Well, it sort of provides confidentiality, except to the proxies, as > > long as the proxies really are as careful with our data as=20 > we asked them=20 > > to be which they may or may not be and we have no way of verifying.=20 > > Sometimes, as Cullen has pointed out, this is good enough,=20 > or at least=20 > > enough better than nothing that it is worth having. > >=20 > > Ok, I am failing to reassure myself here. > >=20 > >=20 > > I'm detecting five different use cases that people are asking for: > >=20 > > 1) I don't care about security, just make it work. > >=20 > > 2) Use as much security as you can, but I'm willing to accept=20 > > downgrades > > without being informed if you must. > >=20 > > 3) I want hop-by-hop security that provides protections roughly > > equivalent to TLS if it were used on a hop-by-hop basis,=20 > and I want my=20 > > request aborted and to be informed on it if you can't make=20 > that happen. > >=20 > > 4) I want hop-by-hop protection using TLS, and I want my request=20 > > aborted > > and to be informed on it if you can't make that happen. > >=20 > > 5) I want my signaling locked-down end-to-end, and insist on being=20 > > able > > to verify that this is the case. And if we exchange media,=20 > I want that=20 > > locked-down too, and I want to be able to verify that too. > >=20 > >=20 > > Right now, I think we're arguing about a) whether sips:=20 > means case 2,=20 > > 3, > > or 4. b) If sips: doesn't include case 2, do we need=20 > another mechanism=20 > > for that, and 3) whether any of case 2, 3, or 4 are really useful. > >=20 > > Personally I see some value in cases 2 and 3, none in case 4 that=20 > > isn't > > achieved by 3, and a whole lot more in the currently=20 > unobtainable case=20 > > 5, for which Vijay has proposed the new URI class "sipsec:" >=20 > Of these, I find only 1,3,5 to be at all interesting. >=20 > Of those, I think 3 falls in the same pot as all the transitive trust=20 > "features" such as P-Asserted-ID, and probably makes sense in those=20 > environments. Its better than nothing if you have a service=20 > provider you=20 > are willing to trust, and it is probably the best we are going to get=20 > from a lot of service providers. >=20 > I would much rather have 5 than 3, but: > - its not at all clear to me that we know how to provide it in a > practical way > - I think a lot of major operators would not wish to provide this > unless forced. (either by laws or competitive pressures.) > - if there is any law on this subject, it would probably be to > ban 5 rather than to require it. :-( >=20 > > 3261, oddly enough, doesn't address any of these use cases.=20 > Rather, it > > says "I want hop-by-hop protection using TLS as far as the proxy=20 > > corresponding to the request-URI, and and I want my request=20 > aborted and=20 > > to be informed on it if you can't make that happen. After=20 > the request=20 > > has reached the node corresponding to the request-URI, I=20 > want as much=20 > > security as possible, but leave the selection and=20 > application of that=20 > > security in the hands of the callee and its supporting=20 > nodes. If the=20 > > callee didn't register with a sips: contact or happens to be a PSTN=20 > > gateway, I still want the call to go through, and I don't=20 > need to be=20 > > notified about the change in the security envelope. > >=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=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=20 > 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 sip-implementors@cs.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 May 31 19:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fla6v-00011b-25; Wed, 31 May 2006 19:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fla6t-00011W-6i for sip@ietf.org; Wed, 31 May 2006 19:28:19 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fla6r-0008AU-Qh for sip@ietf.org; Wed, 31 May 2006 19:28:19 -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 k4VNN4V17890; Wed, 31 May 2006 19:23:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Wacky thead of the month award goes to ... Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips Date: Wed, 31 May 2006 18:28:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF0A2346E6@zrc2hxm0.corp.nortel.com> In-Reply-To: <447DACF3.3020002@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky thead of the month award goes to ... Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips Thread-Index: AcaEwyzl8P5oI8ZBTOWgA56JdG+bKgARq1Vw From: "Francois Audet" To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Cullen Jennings , Sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that does make a lot of sense to me. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, May 31, 2006 07:49 > To: Dean Willis > Cc: Cullen Jennings; Sip > Subject: Re: Wacky thead of the month award goes to ...=20 > Re:[Sip] draft-audet-sip-sips-guidelines: Meaning of sips >=20 >=20 > Dean - you were on a roll yesterday. Again I violently agree. >=20 > Perhaps we need both SIPS and Proxy-Require:link-security. Then the=20 > meaning of sips could be simplified. The sips is an indication of the=20 > target's expectation, while the Proxy-Require is the caller's=20 > expectation. The first node to place a sips URI into the R-URI would=20 > also add the Proxy-Require, in order to honor the target's desires.=20 > Proxies otherwise would simply honor the Proxy-Require. But the=20 > Proxy-Require could also be used with tel or sip if that is what the=20 > caller desires. >=20 > Paul >=20 > Dean Willis wrote: > >=20 > > On May 30, 2006, at 12:02 AM, Cullen Jennings wrote: > >> > >> I think that at the high level, the semantics of sips are=20 > simple. We > >> want it to mean that every hop from the UAC to the UAS was=20 > integrity=20 > >> and confidentiality protected at a reasonable level assuming=20 > >> transitive trust. This can be very useful. At the more=20 > fine details=20 > >> level, we have some parts that are unclear in how to=20 > implement it, we=20 > >> probably have some bugs in the spec, and perhaps we even one place=20 > >> where we made a bad choice that we may correct. I'm very=20 > keen on this=20 > >> draft - I want it to try and sort out the details that are=20 > missing or=20 > >> wrong. > >> > >=20 > >=20 > > "Correcting" the "bad choice" in the proposed way would be=20 > counter to > > the semantics you give above. > >=20 > > It's been proposed that we should change RFC 3261 to=20 > require that, if > > sips: is used, then TLS MUST be used on all hops. This runs=20 > afoul of=20 > > architectures where some other mechanism, notably IPSEC, is=20 > used on some=20 > > hops. > >=20 > > If we make this proposal a requirement, we end up in in a situation > > where we frequently cannot use sips: on the UAC to=20 > serving-proxy hops=20 > > because some other security mechanism is used on the back=20 > side of the=20 > > serving proxy. And since sips: is the only "please secure=20 > me" indicator=20 > > we have, this means that we have no way to request any security=20 > > treatment at all in this situation -- in short, that we're=20 > requiring=20 > > people to NOT secure some links. > >=20 > > This doesn't sound particularly rational. > >=20 > > Perhaps what you really want is a rule more like "Proxies MUST NOT > > forward requests with a sips: URI onto links lacking reasonable=20 > > integrity or confidentiality mechanisms. An example of a reasonable=20 > > mechanism would be TLSThis would be roughly equivalent to a=20 > > "Proxy-Require: link-security" option mechanism that I=20 > recall someone=20 > > else proposing. > >=20 > > This would actually benefit deployability, since it would also allow > > using sips: on calls from UACs that are using non-TLS (but=20 > secure) links=20 > > to their proxies, whereas RFC 3261 as-is allows it only in=20 > the other=20 > > direction. > >=20 > > Now, let's consider retargeting -- the thing that serving proxies do > > when they replace a request-URI with a URI that was registered as a=20 > > contact. It has been proposed that we adopt the rule "Proxies that=20 > > retarget (change the request-URI) MUST NOT retarget a=20 > request that was=20 > > originally targeted to a sips: URI to any other URI type."=20 > Well, that=20 > > sort of does in forwarding your calls to a tel: URI while=20 > still getting=20 > > the exposed SIP links protected. We could perhaps live with=20 > that, but it=20 > > does seem to be a waste. Here at least we could get more=20 > mileage out of=20 > > a proxy-require option tag that requires the resulting tel:=20 > request to=20 > > traverse only secure links. > >=20 > >=20 > > But in any case, sips: remains only a marginal indicator of=20 > security. > > It's kind of like a note by the door of the office that=20 > says "Last one=20 > > out, please lock the door". If somebody forgets, or choses=20 > not to, the=20 > > door isn't locked, and nobody else knows. It's not the lack=20 > of security=20 > > that gets me -- it's the lack of KNOWING that there is no=20 > security. Our=20 > > current usage of sips: is no more secure and generally=20 > applicable to the=20 > > Internet than the trust-domain protections around the privacy of=20 > > P-Asserted-Identity are, and we made that a P-header. > >=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 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=20 > 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 sip-implementors@cs.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 May 31 19:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlaGO-0006e3-Ei; Wed, 31 May 2006 19:38:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlaGM-0006dy-N0 for sip@ietf.org; Wed, 31 May 2006 19:38:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlaGL-000152-Cv for sip@ietf.org; Wed, 31 May 2006 19:38:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 16:38:05 -0700 X-IronPort-AV: i="4.05,195,1146466800"; d="scan'208"; a="286503555:sNHT34772640" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4VNc4iZ001383; Wed, 31 May 2006 16:38:04 -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 k4VNc4CU008198; Wed, 31 May 2006 16:38:04 -0700 (PDT) Received: from [216.102.208.11] (sjc-vpn6-510.cisco.com [10.21.121.254]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4VNYeFo026737; Wed, 31 May 2006 16:34:41 -0700 Message-ID: <447E28E8.7000304@cisco.com> Date: Wed, 31 May 2006 16:38: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: Rohan Mahy Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips References: <015c01c680bf$b123a550$640fa8c0@cis.neustar.com> <447911C5.7050805@softarmor.com> <17529.15626.334110.853151@rautu.tutpro.com> <200605290322.40468.dean.willis@softarmor.com> <1148929672.17999.5.camel@niagra.pingtel.com> <758F0645-1076-44CB-8121-05C921B9B335@cisco.com> <447C45F6.60907@cisco.com> <447C5294.9010107@lucent.com> <447CCACA.10501@cisco.com> <953beacc0605311614g40618ac8n6ca6ab25069fd419@mail.gmail.com> In-Reply-To: <953beacc0605311614g40618ac8n6ca6ab25069fd419@mail.gmail.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=2824; t=1149118684; x=1149982684; c=relaxed/simple; s=sjdkim2001; 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=20Wacky=20thead=20of=20the=20month=20award=20goes=20to=20...=20Re= 3A=20[Sip]=20draft-audet-sip-sips-guidelines=3A=0A=20Meaning=20of=20sips; X=v=3Dcisco.com=3B=20h=3D5Z3eXCg7lQqehgEB9HfS2i5thd0=3D; b=CS6qkeFnp3Nhq52GPPR3fPeTkKo3MHKuzOTScKSVLI13x9TX5OkqbSwHCgslLyfhObPhJBY1 CbKAtrudiVjRjKZb6L0sR3HF/wdFgz9hGcx2tM9isFEKoDtMlZohugyn; X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Sip , "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 You're undoubtably right -- I've been wondering about this -- so let me say that my problem is with anything that supposedly dictates security beyond what the next hop is but cannot be verified by the would be dictator. Barring end to end security of some form, anything that purports to elevate the authenticity and/or confidentiality of the signaling is bound to be misinterpretred, and that's what sips real sin is. If this is really a BCP -- which I'm becoming convinced is the only way to reasonably sell -- not oversell -- this desire, then we should work in that direction. Signaling for security that one has no means of verifying is just plain dumb. Mike Rohan Mahy wrote: > Michael, > > You seem to have a mistaken impression that transport=tls means > something it does not/is actually useful. Unfortunately, > transport=tls only affects the next hop, it interferes with NAPTR > selection of the actual underlying transport (TCP, UDP, SCTP, DCCP), > it looks really ugly in URIs, and it is a pain in the arse to enter on > a phone keypad. > > I don't really believe the last two are a big deal, but the important > thing here is that sips: has the semantics that most folks think > transport=tls should have, but transport=tls actually does not have. > > thanks, > -rohan > > > On 5/30/06, Michael Thomas wrote: > >> Vijay K. Gurbani wrote: >> >> > Michael Thomas wrote: >> > >> >> My question is whether it's answer to _any_ problem. My last >> attempt at >> >> getting and answer was fruitless. What attacks do SIPS thwart in real >> >> life >> >> that honest operators and transport=tls doesn't? Real life good guy, >> >> bad guy situations would be helpful. >> > >> > >> > Sorry -- catching up after a forced, and not entirely un-welcome, >> > lull introduced by the weekend. >> > >> > Dean has pointed out one answer to this; namely, "reduces the >> > probability of an accidental downgrade by intermediate proxies >> > between the UAC and the proxy responsible for the AOR, if those >> > proxies bother to honor it." >> >> >> How does it do that? Why does this sort of behavior require an ill >> conceived protocol element when it is really a BCP in disguise? >> >> > >> > A couple more: sips provides confidentiality of traffic >> > and authentication of a proxy and registrar to a UAC. Admittedly, >> > one could do this with transport=tls, but this particular >> > construct is deprecated in rfc3261. Currently, there is no means >> > for a UAC to authenticate a registrar or a proxy; sips at the >> > very least, allows for the signaling between the UAC and a >> > registrar to be on an confidential and authenticated channel. >> >> >> So SIPS is overloaded with transport=tls; Bletch. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip